The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
У вас есть команда блестящих и энтузиастичных программистов? Конечно! Вы тщательно выбрали их из сотни кандидатов! Они увлечены продуктом? Безусловно! Они используют передовые технологии, не спят, едят и пьют только кофе! Верят ли они в успех вашего бизнеса? Без сомнений! Они живут и дышат всеми этими функциями, релизами, непрерывной поставкой, пользовательским опытом и т.д. Вы уверены, что они разрабатывают продукт правильно? Ну, да, вы довольно уверены; почему бы и нет? …
Звучит знакомо? Не могу сосчитать, сколько раз я слышал эти истории от основателей стартапов. Большинство из них влюблены в свои команды… до тех пор, пока не приходит время нанять новую. Причин для такого фиаско может быть много, но одна из них - отсутствие регулярных, систематических и независимых технических обзоров. Ничто не снижает мотивацию разработчиков больше, чем недостаток внимания к их результатам. С другой стороны, регулярное согласование их результатов с вашими ожиданиями по качеству - один из ключевых факторов, гарантирующих технический успех вашего стартапа. Ниже я резюмирую свой опыт организации таких технических обзоров.
Независимый обзор - это когда вы просите кого-то извне вашей команды посмотреть на ваш исходный код и другие технические ресурсы и дать вам объективное мнение о них. Каждая современная команда разработчиков программного обеспечения также должна использовать внутренние обзоры кода, что является совсем другим. Внутренний обзор происходит, когда один программист показывает свой код другим участникам команды и просит их мнения. Обычно это происходит ежедневно и не имеет ничего общего с независимыми обзорами.
Независимый обзор проводится программистом, который ничего не знает о вашей команде. Он приходит на борт, проверяет код из вашего репозитория, проводит несколько часов (или дней), изучая его и пытаясь понять, что он делает. Затем он говорит вам, что не так и где. Он объясняет, как он сделал бы это лучше, где бы он изменил это и что бы он сделал вместо этого. Затем вы платите ему, и он уходит. Возможно, вы никогда больше не увидите его, но его выводы и предложения помогут вам проверить реальность вашего кода и оценить, как на самом деле работает ваша команда.
Мы в Zerocracy проводим независимые обзоры с каждым нашим проектом, и вот список принципов, которыми мы руководствуемся:
Сделайте независимые обзоры систематическими. Это первое и самое важное правило - организуйте такие технические обзоры регулярно. Кроме того, сообщите своей команде о графике и позвольте им быть готовыми к обзорам. Раз в месяц - это хорошая практика, согласно моему опыту. В зависимости от объема вашего исходного кода, полный обзор должен занимать от двух до восьми часов. Не тратьте больше восьми часов; нет смысла слишком углубляться в код во время независимых обзоров.
Платите за найденные ошибки. Мы всегда платим за ошибки, а не за время, затраченное на их поиск. Мы просим наших рецензентов посмотреть на код и сообщить о стольких ошибках, сколько мы считаем нужным. За каждую ошибку мы платим 15 минут за их время. Другими словами, мы предполагаем, что хороший рецензент может найти и сообщить примерно о четырех проблемах за час. Например, рецензент берет $150 в час. Мы нанимаем его и просим найти и сообщить о 20 самых критических проблемах, которые он может обнаружить. Мы предполагаем, что он потратит на это работу пять часов. Таким образом, он получит $750, когда у нас будет 20 ошибок в нашей системе отслеживания, сообщенных им. Если он найдет меньше, он получит пропорционально меньше денег. Эта платежная схема поможет вам сосредоточиться рецензента на основной цели процесса обзора - нахождении и сообщении о проблемах. Других целей нет. Вас интересует только то, что не так с вашим текущим техническим решением. За это вы платите.
Наймите лучших и хорошо платите. Мой опыт говорит мне, что должность независимого рецензента - это очень важная роль. Он не просто программист, а скорее архитектор, способный смотреть на решение с очень высокого уровня абстракции, при этом уделяя много внимания деталям; он должен быть очень хорош в проектировании подобных систем; он должен знать, как правильно сообщать об ошибке и с достаточной детализацией; он должен понимать вашу деловую область и т.д. Помимо всего этого, он должен быть мотивирован помочь вам. Вы нанимаете его не на полный рабочий день, а только на несколько часов. Мой совет - попытаться найти лучших парней и платить им столько, сколько они просят, обычно более $100 в час. Не ведите переговоры, просто платите. Для вас это всего
Отслеживайте, как разрешаются несоответствия. После получения отчета от рецензента убедитесь, что самые важные проблемы сразу попадают в список задач вашей команды. Затем убедитесь, что они решаются и закрываются. Это не означает, что вы должны исправить все и прислушаться ко всему, сказанному рецензентом. Определенно нет! Ваш архитектор управляет процессом, а не рецензент. Ваш архитектор должен решать, что является правильным и что является неправильным в технической реализации продукта. Но важно, чтобы он разрешал все возникшие проблемы, высказанные рецензентом. Очень часто вы будете получать ответы от него вроде: «Сейчас нам все равно на это», «мы исправим это только в следующем релизе» или «он неправильно мыслит; мы делаем это лучше». Эти ответы вполне допустимы, но их нужно давать (рецензенты тоже люди и они тоже ошибаются). Они помогут вам, основателю, понять, что делает ваша команда и насколько хорошо они понимают свой бизнес.
Если у вас есть еще предложения, основанные на вашем опыте, пожалуйста, оставьте их ниже в комментариях, и я добавлю их в список. Я все еще считаю, что мог забыть что-то важное.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-17 at 15:36
