3 главных вопроса в ремесле программиста
Вы когда-нибудь были в ситуации, когда ваша имейл-переписка становилась все длиннее, а история коммитов все короче? Вы когда-то проклинали напоминание в календаре об очередном бесконечном и никому не нужном митинге? У вас когда-то шла голова кругом от постоянных и непредсказуемых изменений требований и задач на проекте? У меня да.
При том, что я не проджект-менеджер и не продукт-менеджер. И не менеджер совсем. Я программист. И не хочу тратить большую часть своего времени на разговоры ни о чем в душных митинг-румах с кучей малознакомых мужчин. Я хочу программировать.
И для таких случаев, когда мой проект начинает уводить в сторону от оптимальной траектории развития, я выработал 3 главных вопроса, ответы на которые позволяют мне быстро сориентироваться в пространстве и дальше делать мою любимую работу.
Для простоты предположим, что структура команды более-менее постоянна (никто не увольняется, и никого не нанимают).
Кто мы?
Основной вопрос для каждой команды. Без понимания своей команды очень сложно сопоставить ожидание и реальность от ее действий.
Вы можете спросить себя:
- Сколько нас в команде?
- Насколько высок наш уровень подготовки?
- Каковы наши мотивы?
Этот вопрос помогает понять свою команду, ее возможности и ограничения. Если вы группа JS-девов, то вам вряд ли стоит браться за embedded-разработку. Так же как не имеет большого смысла отправлять человека с 15 годами опыта С++ разработки на разработку сайта для продажи кошачьего корма.
Если вы в команде единственный сеньор, а вокруг вас вертится стайка неокрепших морально джунов, то стоит придерживаться консервативных, хорошо известных техник и фреймворков. А не браться за самый новый стек технологий и загонять свою команду на пустынную страничку в Stack Overflow с вопросом без ответов: «A как же эта новая мегаштука должна парсить JSON?».
Где мы?
Где мы — это насущный вопрос. Потому что он относится к крайне ценному ресурсу — времени. Возможно, имеет смысл перефразировать этот вопрос в «Когда мы?». Но боюсь, если вы зададите вашему боссу такой вопрос, то надолго на этой работе вы не задержитесь :)
Необходимо понять тип проекта/продукта, над которым вы работаете. И на каком этапе разработки он находится. А также понимать состояние компании, в который вы работаете.
Попробуйте спросить себя:
- Мы делаем продукт?
- Мы работаем как аутсорс/аутстаф?
- Мы позиционируем себя как IT-consulting?
- Мы большая компания?
- Мы маленькая компания?
- Мы в начале/середине/конце большого/среднего/маленького проекта?
- Мы на этапе поддержки продукта?
Переводить большой проект на другой тип базы данных перед релизом — не самая хорошая идея. В тоже время просто писать код без оглядки на документацию и автотесты может быть вполне оправданной стратегией для маленькой команды в стартапе.
Куда мы идем?
Сколько раз молчание было ответом на этот проклятый вопрос! Точка назначения предельно важна для успеха проекта. Без поставленной цели нельзя даже толком измерить результат работы команды.
В основном вас должны интересовать ближайшие майлстоуны и даты релизов. А также функционал, который необходимо предоставить.
К примеру:
- Ожидается ли в ближайший месяц major release новой пачки фич?
- Должны ли мы как можно быстрее выпустить MVP?
- Когда ближайшее демо для стейкхолдеров?
- Должны ли мы за короткое время выйти в лайв и ожидать пачки багов для экстренного фикса от реальных клиентов?
Если все, что вас ожидает, это внутреннее демо для команды, то не стоит тратить слишком много времени на CI/CD и документацию. Но если вы делаете major release вашей библиотеки, который поломает половину старых API, — следует отнестись к документированию изменения как можно более серьезно.
Если вы идете в лайв в первый раз — будьте готовы к быстрому фиксу багов ваших живых клиентов.
К сожалению, порой никто, абсолютно никто не может дать ответа на этот вопрос. В таких случаях я обычно переформулирую вопрос в «Как понять, куда мы идем?». Пишу пару писем людям, которые могли бы хоть что-то об этом знать. А потом отправляюсь запускаю static analyzer и начинаю править код проекта :)
Профит
Все вышеперечисленное звучит очевидно. Тогда в чем смысл этой статьи? Где профит? Для меня профит начинается, когда мы комбинируем все три вопроса воедино и начинаем действовать согласно ответам.
К примеру, рассмотрим следующую ситуацию:
- Вы маленькая команда в большой компании с задачей мейнтейнить старую систему с очень большой пользовательской активностью.
Оптимальным вариантом, скорее всего, будет просто мейнтейнить старый код с минимально необходимыми изменениями для баг-фикса. Если бы вы не задали себе 3 главных вопроса, то вполне могли бы поддаться инстинкту и начать рефакторить плесневелый спагетти-код, который вам достался в наследство от предыдущих поколений. С очень большой вероятностью положить крайне важный для компании сервис, не имея достаточных ресурсов, чтобы быстро восстановить его работоспособность.
С другой стороны:
- Вы большая команда в большой компании с задачей мейнтейнить старую систему с очень большой пользовательской активностью.
В этом случае вы можете выделить некоторых ваших членов команды для рефакторинга старого кода в безопасной, изолированной среде с должным QA. А затем плавно перевести новый code base в лайв.
Еще один пример:
- Вы маленькая команда в маленьком стартапе, которая должна безумно быстро разработать продукт, чтобы получить следующий раунд инвестиций для вашей компании.
В этом случае вам следует запастись пачкой кофе и начать выдавать на-гора как можно больше кода, не сильно отвлекаясь на то, как он пахнет. Качество вашего кода не будет иметь никакого значения, если вы не предоставите результат достаточно быстро для получения денег на продолжение проекта.
Сравните с такой ситуацией:
- Вы средняя по размеру команда в стартапе, который уже набрал некоторую популярность. И теперь вы соревнуетесь за внимание широкого круга пользователей.
Вы все еще должны двигаться быстро. Но теперь качество вашего продукта будет требовать большего внимания. Вы не хотите потерять существующих и отпугнуть потенциальных пользователей из-за неуклюжего апдейта или security breach в вашем продукте. Теперь вам следует найти баланс между качеством кода и скоростью разработки.
Надеюсь, теперь вы можете увидеть, как в зависимости от того, где вы, кто вы, куда идете, вы можете выбирать нужные инструменты и подходы для решения ваших проблем.
Итеративность
Процесс разработки ПО имеет итеративный характер, иногда. Соответственно, следует задавать себе 3 главных вопроса перед каждой итерацией.
Ответственность и лидерство
Одна маленькая, но важная деталь — ответы на эти вопросы требуют некоторой степени ответственности и лидерства. Иногда вы не сможете получить внятные ответы на ваши вопросы не потому, что их нет. А потому, что никто не хочет брать на себя ответственность за ответы на них.
И, учитывая, что каждый вопрос — это уже половина ответа, вы можете обнаружить себя в лидерской роли, просто задав эти 3 вопроса достаточно громко, чтобы вас услышала команда.
Вывод
Ремесло программиста — это динамичный процесс принятия сотни решений в условиях серьезного ограничения по времени и недостатка информации. И здесь нет идеальных ответов для всех команд и проектов. Но есть правильные вопросы для вашей команды и проекта. А правильные вопросы дают правильные ответы.
