Как соучредитель и случайный внештатный менеджер по продукту, дизайнер и разработчик, я работал по обе стороны таблицы: как управляемый разработчик, и как менеджер, работающий с разработчиком.
Поэтому, если вы являетесь основателем, менеджером по продукту или кем-то, кто работает в технической команде, я хочу поделиться несколькими вещами, которые помогут вашим сотрудникам быть счастливыми и облегчить их жизнь.
Зачем беспокоиться? Что ж, кроме простого желания быть хорошим руководителем, чем проще жизнь вашего разработчика, тем быстрее и эффективнее он сможет реализовывать функции. И в Интернете, где время движется со скоростью собачьих лет, это определенно преимущество.
Вот ключи к успеху при работе с вашей технической командой.
Понять разницу между техническим директором и ведущим инженером
Вы либо будете работать с техническим директором или ведущим инженером, и важно понимать, что это не обязательно один и тот же человек.
Иногда у вас есть замечательный технический директор, который не только технический, но и отличный менеджер, коммуникатор и делегатор. Эти типы, вероятно, хотят знать все о том, что вы создаете, какова конечная цель для пользователя и ваши общие бизнес-цели. Замечательно! Поверьте мне, это актив. Берегите это.
Однако в большинстве случаев, особенно в условиях дефицита разработчиков, у вас будет ведущий инженер: человек, который отлично разбирается в разработке продукта, но не обязательно обладает навыками (или желанием) управлять командой и продукт.
Чем быстрее вы поймете, какого типа человек вам нужен (или нанял), тем лучше вы подготовитесь к тому, чтобы управлять этим человеком и продуктом.
Забота о том, как вещи
Разработчики - производители, а не машины. Поэтому выслушайте их идеи и убедитесь, что вы их учитываете, даже если не знаете, о чем, черт возьми, они говорят, когда начинают разбрасываться техническими терминами. Не знаете разницу между этим и этим стеком? Просить. Используйте это как возможность учиться. У вас должно быть хотя бы базовое понимание технической стороны вашего продукта.
Быть конкретными
Вашей технической команде гораздо полезнее назначать им конкретные небольшие задачи - не просто раздать кучу макетов и сказать, что они должны быть выполнены к пятнице. Фактически, именно вы должны управлять им. Узнайте, как использовать программное обеспечение для управления проектами, такое как Pivotal Tracker или Trello, и отслеживать ход разработки функций по дням или за рабочую сессию.
И проверяйте часто, как лично, так и через ваше программное обеспечение для управления проектами. Гораздо проще не допустить, чтобы вещи пошли по неверному пути, если вы можете поймать их на развилке.
Не меняй свое мнение каждый день
Я знаю, вы думаете, это звучит очевидно. Но когда вы продвигаете и продаете свой продукт каждый день, слышите отзывы и проводите мозговые штурмы, чтобы сделать его лучше - действительно легко возвращаться с новыми идеями все время. Не делай этого со своей командой.
Определите конкретную и небольшую вещь, которую вы хотите создать: минимально жизнеспособный продукт (или «MVP»). Подготовьте ваш MVP и будьте готовы к сборке. И сделай это маленьким. Если вы разработали гигантское приложение, разбейте его и начните с одной части. Отправьте свой MVP, а затем измените свое мнение на основе данных.
Кроме того, если вы еще этого не сделали, прочитайте книгу Эрик Райс « Постный запуск ». Следуйте за этим - не просто бросайте крутой жаргон на сетевых мероприятиях.
Ставьте цели, а не сроки
В техническом мире сроки не всегда работают. Даже самый опытный разработчик ломает вещи, и оценить, сколько времени потребуется, чтобы все исправить, сложно.
Мне действительно нравится идея трекера разбивать функции и назначать очки сложности, а не часы. Пометьте проблему как «легкую», «среднюю» или «сложную» и отслеживайте прогресс, а не придерживайтесь сроков. Назначать в основном сложные задачи? Они, вероятно, могут быть разбиты дальше.
Получить великого дизайнера
Дизайнеры решают проблемы и могут значительно упростить процесс сборки продукта. Особенно дизайнеры UX / UI (пользовательский интерфейс и пользовательский интерфейс). Они помогают вам понять, как ваш продукт должен выглядеть и вести себя - пиксель за пикселем, взаимодействие пользователя с взаимодействием пользователя (подумайте: какую кнопку нажимает пользователь дальше? Где он находится на странице? Куда он ее ведет?).
Это не работа вашего разработчика. Я серьезно. Задача вашего разработчика - писать код, а не разрабатывать продукт. Хороший дизайнер на самом деле поможет вам сэкономить на затратах на разработку, потому что они помогут команде продумать и поймать вещи, которые другие могли упустить из виду. Они также могут предложить сделать простые, но мощные изменения, которые сделают ваш продукт более интуитивным и простым в использовании.
В то же время убедитесь, что ваш дизайнер худой. Иногда это не стоит затрат, чтобы построить все на заказ. Есть разница между вниманием к деталям и дива. Если ваш разработчик жалуется на дизайн - это признак того, что вам нужно остановиться, обсудить его, настроить его и пойти на компромисс.
Тест, Тест, Тест
Если вам небезразличен ваш продукт, помогите разработчику протестировать его. Она смотрела на это часами. Дайте ей новый набор глаз. Хвалите ее за то, что она сделала правильно, и дайте ей конкретные задачи для того, что еще нужно сделать или исправить.
Разработчики часто жалуются мне на то, что они потратили кучу времени на что-то, а потом все началось с поломанных вещей, потому что никто их не видел. Помните, это ваш продукт. И никто не хочет работать на кого-то, кому нет дела до продукта, который они там выпускают.
Компенсация справедливо
Вы деловой человек, и деловые люди ведут переговоры. Обычно намного лучше, чем некоммерческие люди.
Так что будьте осторожны.
Вы можете договориться с разработчиком о ее ставке, но если это звучит разумно, это, вероятно, так. Имейте в виду, что есть много других людей, желающих и способных нанять ее за то, что она процитировала. И, если она чувствует, что с ней договорились, и ей не выплачивают компенсацию того, что она стоит, есть вероятность, что она не будет расставлять приоритеты в вашей работе над другой работой (или над другими, более веселыми вещами). Или она найдет кого-то еще, кто заплатит ее цену, а затем оставит вас в покое. Я видел это снова и снова.
Альтернатива - договориться о цене пробного периода для небольшой функции и сказать ей, что вы заплатите полную цену, если проект пойдет хорошо.
Доверься своей команде
Вы с подозрением относитесь к тому, что ваш разработчик отрабатывает часы работы или ослабевает, отправляясь в ближайший биргартен? Помните, что если вы не нанимаете людей, которым доверяете и которые лучше чем вы в чем-то, то вы не нанимаете нужных людей.
Доверьтесь экспертам, которых вы наняли для выполнения своей работы. Дайте им инструменты, необходимые для этого, в том числе направление, гибкость, передышку и авторитет. И проверять часто.
