Как руководить разработкой в продуктовой компании: чеклист для стартапера

В чем заключается работа технического директора? Обычно я отвечаю отрывочно или углубляюсь в какой-то аспект профессии, который интересует меня в тот момент.

Мы с Федей уже почти месяц вместе составляем системный ответ на этот вопрос. Для командной работы мы завели личную базу знаний (что-то вроде своей википедии) в Notion. Мы храним там общие задачи, план и знания, которые собрали в ходе работы. Если заменить информацию о конкретном клиенте подробным описанием, зачем мы делаем тот или иной шаг — может получиться книга «как руководить разработкой в продуктовой компании».

Вот структура/оглавление, которые у нас сложились. Этот список можно использовать как основу чеклиста для стартапа или небольшой технологической компании.

Глава I: бизнес и процессы

1. Чего бизнес хочет от разработки? Важно не остановиться на конкретной хотелке «напрогайте нам X», а докопаться до бизнес-гипотезы, которую хотят проверить.
2. Как построена работа над продуктом: кто преобразует гипотезу в задачу, как ставится задача разработке, доносится ли гипотеза до программиста, интересуется ли они ею? В здоровой продуктовой команде техническая экспертиза подключается на самом раннем этапе.
   
3. Что происходит после запуска фичи? Анализируется ли результат? Понимают ли программисты, как они повлияли на бизнес?
   
4. Как происходит планирование и приемка работы? Смотрим на четкость и ритмичность. Четкость: плохо — «мы тут что-то не особо хорошо описанное напланировали, о том успеем или нет — не задумывались», хорошо — «в понедельник у пользователей в продакшене появится X», нужны конкретные обещания и контроль их выполнения. Ритмичность: продуктовая работа — это почти всегда постепенное улучшение и очень редко — один героический забег. Чтобы система работала годами, ей нужна цикличность, с запланированными фазами «напряжение-расслабление».
   
   Глава II: люди
   
5. Команда: в каком состоянии ребята, нравится ли им работа, нравятся ли коллеги, конкурентная ли компенсация? План развития ребят, 360 reviews, 1-1.
   
6. Уникальность знания. Что будет, если сотрудник уволится или заболеет (bus factor)? Документация, стоимость погружения новых людей в проект.
   
   Глава III: технологии
   
7. HR: достаточно ли мы рассказываем миру о том, хорошо ли у нас работать? Ведение профессионального блога, выступление на профильных конференциях.
   
8. Operations: отказоустойчивость, масштабируемость, мониторинг, incident management, бэкапы, учения. Автоматизация процессов в разработке: среды разработки, деплой, откат, etc.
   
9. Архитектура и код: модульность, связанность, тесты. Тесты: насколько велика вероятность сломать проект? Радость разработчика: насколько комфортно ребятам работать?
   
10. Информационная безопасность: DDoS, дырки в коде, операционная безопасность, социальная инженерия. Проводим ли ли пентесты, есть ли баунти-программа, как реагируем на сообщения об уязвимостях?
    

—

Федя шутит, что это — опасная книга, люди увидят, что работа довольно простая и платить нам за неё много денег необязательно. Я так не думаю, сложности с количеством клиентов нет, и кайф, что нам не стыдно открыть кухню. Получится самим улучшить ситуацию по нашей инструкции — отлично.

Проблемы, которые мы видим на рынке у разных компаний, — очень схожи. Но этот пост уже и так неприлично длинный, об этом — в следующий раз.

Источник

Читайте также:

Пять историй от бывшего технического директора Avito

Как небольшая компания из России помогает армии США, Google и UEFA моделировать реальный мир

Почему идеальный пользовательский опыт достигается при нулевом интерфейсе

Что общего у обезьян и пользователей соцсетей

Почему у одних соцсетей получилось стать сервисами, а у других никогда не получится