Настоящий CTO: думай как технический директор - Алан Уильямсон

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

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

Разработчики и инженеры не всегда следят за актуальным статусом задач. Здесь также на помощь приходит руководитель проектов, который следит за своевременным обновлением тикетов, а лучшие проджект-менеджеры показывают всем важность этого и таким образом приучают всех делать это без напоминаний. Подавляющее большинство своих отчетов и текущей работы руководитель проектов выполняет в системе управления задачами, поэтому в его интересах добиваться актуальности данных в его главном инструменте. Также в этой главе я покажу, как система управления задачами может помочь в планировании релизов.

9.1.2. Что считать проектом

Общее определение проекта ни у кого не вызывает возражений: это набор связанных друг с другом задач, выполнение которых приводит к желаемому результату. Разногласия возникают при обсуждении масштаба: насколько большая задача может считаться проектом? Проект может быть рассчитан как на несколько дней, так и на годы. Независимо от продолжительности, у проекта должна быть конкретная цель – основная причина, по которой он существует. Цель не говорит о том, какими способами и в какие сроки она должна быть достигнута. Она всего лишь определяет критерии успеха, выполнение которых означает, что проект завершен.

Цели проекта необходимо сформулировать языком, понятным не-разработчикам. Это обеспечит прозрачность и более эффективную коммуникацию, особенно с генеральным/финансовым директором, которым нужно знать, на что вы и ваша команда тратите время и деньги. Ниже приведены два разных описания целей одного и того же проекта:

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

• Внешнее описание. Модернизировать процесс подключения новых клиентов, переписав его для облака, чтобы повысить гибкость и скорость работы.

Определение результата проекта – это легкая часть. Теперь необходимо понять, как добиться этого результата. Для этого нужно разбить основную задачу на более мелкие, выполнение которых приведет нас к цели. В IT существует два основных подхода к реализации проектов. Традиционный подход называется каскадным, или же «водопадом» (waterfall), а целый набор более современных подходов – гибкими методологиями разработки, или agile.

КАСКАДНЫЙ ПОДХОД (ВОДОПАД)

Эта модель предполагает максимальную степень планирования до начала работ. Идея здесь в том, что, как в водопаде, все начинается сверху и движется только вниз. Основной акцент делается на анализе предметной области, при котором выявляются все задачи и проблемы, которые необходимо решить. Затем принимаются основные решения, касающиеся архитектуры и деталей реализации. Каскадная модель ставит целью получить как можно больше данных, прежде чем выделять ресурсы для проекта.

На предварительное планирование уходит много времени, но чем четче определен проект – тем проще спрогнозировать для него сроки и стоимость работ. Кроме того, такие проекты благодаря своей продуманности отлично подходят для участия во внешних тендерах.

Однако то, что на детализацию и планирование проекта уходит много времени, является и одним из основных недостатков каскадного подхода, особенно если проект крупный, потому что, пока планирование не будет завершено, приступать к реализации нельзя. Представьте проект, цель которого – доехать из Майами в Сан-Франциско: команда не сможет начать движение, пока маршрут не будет проработан во всех деталях.

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

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

ГИБКИЙ ПОДХОД (AGILE)

Если водопадная модель предполагает, что все детали должны быть известны до начала проекта, то на другом конце спектра находятся гибкие методологии, при использовании которых проблемы решаются по мере их появления. (На самом деле это упрощение – бывает, что только отдельные проблемы не исследуются или не решаются до начала разработки.) Гибкий (agile) – значит способный адаптироваться к изменяющейся среде, поэтапно приближающийся к конечному результату, быстро и успешно реагирующий на изменения. Например, вернемся к нашему проекту поездки в Сан-Франциско, на этот раз использовав гибкую методологию: поняв, как ехать по штату Флорида, мы разрешаем команде двигаться к его границе, одновременно с этим планируя следующие шаги. Гибкие методологии – это набор руководящих принципов, обеспечивающих непрерывное внедрение результатов работы и вовлечение в процесс всех заинтересованных сторон, включая конечного клиента или пользователя, для обеспечения высокого качества, поскольку при этом проблемы выявляются и устраняются гораздо быстрее.

Многие считают, что гибкий подход – это просто отсутствие планирования, что абсолютно неверно. Такие проекты точно так же требуют планирования, просто не такого подробного, как при каскадном подходе. Для них определяются промежуточные цели (или, в agile-терминологии, эпики), они затем превращаются в набор задач, которые можно брать в работу. Затем эти задачи объединяются в ограниченные по размеру периоды работы, или спринты. Обычно они продолжаются 1–2 недели, и после каждого спринта проводится разбор итогов. Как правило, по результатам каждого спринта какая-то часть функционала должна быть уже готова к использованию, чтобы другие по возможности могли начинать работать с ней.

Agile может быть ориентирован в первую очередь на процессы, что поначалу может пугать. Но это скорее набор руководящих принципов, чем строгих правил, которым необходимо обязательно следовать, – то есть структура, обеспечивающая необходимый уровень порядка и последовательность действий там, где это нужно. Некоторые организации настолько зацикливаются на правилах, что работа лишается всякого удовольствия и творческого подхода. Секрет успеха гибкой методологии состоит в том, чтобы найти баланс, подходящий именно для вашей команды. В качестве одного из примеров гибких подходов к разработке можно привести методологию скрам (scrum).

Гибкий подход значительно упрощает внесение изменений, поскольку позволяет увидеть, работает ли решение, до того, как на него будет потрачено слишком много ресурсов. Способность адаптироваться – вот ключ к успеху agile. Для того чтобы внедрить ту или иную методологию, сначала определите и формализуйте области, в которых не потребуется менять привычный вам порядок работы, а затем постепенно адаптируйте остальные процессы, позволяя команде привыкнуть к новой организации работы по мере того, как она начинает приносить плоды. Более подробный обзор гибкой и каскадной методологий можно найти здесь: https://www.guru99.com/waterfall-vs-agile.html.

9.2. Стандарты разработки

Хотя велик соблазн просто позволить командам разработчиков работать как им удобно, без стандартов и правил, это создаст проблемы в будущем по мере роста проекта. Вы не захотите иметь дело с большими блоками кода, от которых зависит успешная работа всего бизнеса, но которые при этом до такой степени сложные и хрупкие, что только горстка людей осмеливается вносить в них изменения. В каждой компании есть свои «священные блоки кода», обросшие мифами из-за их легендарной сложности, и когда кто-нибудь предлагает их переписать – ответом ему бывают долгие, тяжкие вздохи, а старожилы команды качают головами и советуют вообще не трогать этот код, не то что пытаться его переписать.

Как уже неоднократно отмечалось, технический руководитель должен не только решать текущие проблемы,