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 вопроса достаточно громко, чтобы вас услышала команда.

Вывод

Ремесло программиста — это динамичный процесс принятия сотни решений в условиях серьезного ограничения по времени и недостатка информации. И здесь нет идеальных ответов для всех команд и проектов. Но есть правильные вопросы для вашей команды и проекта. А правильные вопросы дают правильные ответы.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



27 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Вы когда-то проклинали напоминание в календаре об очередном бесконечном и никому не нужном митинге?

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

— Кто мы?
— Манагеры!
— Когда мы хотим финальный билд?
— ASAP!!!
— Что мы для этого сделаем?
— Больше митингов!

«Хотите об этом поговорить?» (к) (тм)
«А придётся!» (к) (тм)

хорошая статья, коротко и по делу.

Навеяло статьей — много-много лет назад еще в университете короткий курс психологии у нас вела практикующий психолог. Единственное, что помню из курса — ее фраза про три коротких вопроса самому себе, на которые нужно ответить, чтобы убедиться, что (не дословно) еще не превратился в овощ / находишься в здравом рассудке: кто я? что я сейчас делаю (чем занимаюсь)? зачем я это делаю?

для чего ты занимаешься жизнью?

для чего ты занимаешься тем, чем занимаешься сейчас.
Как пример — для чего ты работаешь на этой работе / делаешь этот код и т.д.

Будете давать мне по 30 золотых динаров в месяц за то, что я каждый день буду задавать вам эти вопросы?

Запитання рівня менеджменту. Програмістам на них пофігу.

Чего мы хотим?

А мы чего-то хотим?

Да, как насчёт пивком накидаться?

Правда ли что в Украине импортное пиво совсем подорожало?

Если год с зарплаты откладывать, можно себе разок позволить. Главное — в валюте хранить.

Главное — в валюте хранить.

Может тогда сразу в пиве? ))

Выдохнется же.

Так не наливать же ж!

Хранить на депозите, а потом друзьям выписывать чеки?

друзьям выписывать чеки?

Литровыми кружками!

Хорошо сформулированы вопросы, на обнаружение которых у меня лично ушла куча нервов в серии разборок с начальством и увольнений.
Спасибо)

Ну и в аутсорсе могут не любить такие вопросы — когда важно, чтобы на проекте работало побольше людей, и он подольше не заканчивался.

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

Команда может объединяться общей целью, лучше, наверно, бизнес-целью, которая диктует в том числе конфигурацию команды? Когда цель ясна, правила понятны, то желание:

Я хочу программировать.

Это уже почти мотивация и митинги становятся нужнее нам, так как могут изменить цель согласно бизнес-требованиям? Цель митинга же понять как до этой цели добраться эффективнее?

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

Группа программстов, ктороая почему-то вместе (команда) — я думаю целесообразна почти всегда

Когда такое возможно, что есть какая-то стабильная общность программистов, как одно неделимое целое?

В аутсорсе/аутсафе почти никогда. Возможны горизонтальные связи среди людей, работающие на разные проекты. И объединенных единой культурой. Но вряд-ли больше.
В продукте стабильные команды гораздо более частое явление.

Когда цель ясна, правила понятны, то желание:

— да, когда цель ясна и правила понятны — все хорошо)

Мои вопросы как ра- предназначены для случаев когда цуль не ясна, и правла тоже)

Да, когда цель не ясна и правила — гораздо сложнее. Мне кажется, лучше их выяснить попытаться, а если невозможно — предложить свои. Если и это невозможно, то... формализовать миссию так или иначе? Без этого вообще непонятно зачем это все.

Підписатись на коментарі