Предположим, вам нужно добавить в приложение новую важную функцию. Какой из двух сценариев проще?
- добавить эту функцию в относительно небольшое приложение, которое все еще находится в разработке, но еще не в производстве
- добавить эту функцию в приложение, которое со временем разрослось, общее качество которого вызывает сомнения, которое уже запущено в производственной среде и обслуживает нескольких клиентов.
Что ж, сомнений нет. Вторая задача - гораздо более сложная.
Но тогда почему мы обычно находим более опытную команду старшего возраста в первой и больше юниорских команд, похороненных во второй?
Много лет назад
Когда я вошел в команду, которая разрабатывала новую платежную систему для крупного европейского банка, первое место, которое мне дали, было в группе обслуживания приложений (AM), ответственной за унаследованные части. Причины были простыми и общими: я был новичком в этом месте, новые проекты выполнялись быстро, с использованием передовых технологий, для которых не было большого опыта. AM был бы подходящим местом для меня, чтобы расти без особого давления. Как только я накопил достаточно знаний и опыта, я бы перешел в команду Project, команду, разрабатывающую новые функции с новыми технологиями, команду крутых людей. Примерно через год это действительно произошло, но я никогда не забуду этот якобы не такой уж стрессовый период AM.
Команда проекта и команда AM
Все это восходит к прошлому тысячелетию, но с тех пор я видел, как один и тот же образец повторялся бесконечное количество раз, часто в гораздо более экстремальных формах. У вас есть новая инициатива, вы начинаете с команды проекта. Команда проекта разрабатывает архитектуру, команда проекта разрабатывает функции, команда проекта накапливает задержки относительно очень оптимистичного начального плана, команда проекта начинает работать сверхурочно, команда проекта начинает срезать углы. Качество часто приносится в жертву Алтарю Плана, тесты забываются, а патчи добавляются поверх патчей. Разработчики начинают добавлять комментарии: «На рефакторинг, как только у нас будет время». Технический долг уже есть, и его судьба - расти.
В конце концов, вещь запускается в производство, а затем, сразу после запуска, команда проекта начинает переход к команде AM. После некоторого периода перекрытия команда AM остается в одиночестве. Команда AM обычно моложе, менее опытна и считается менее сильной, чем команда Project. Самое сложное позади, проект жив. Настало время утра, это проще, это должно стоить дешевле, мы можем позволить себе новую молодежную команду.
Через год после выхода в эфир
Это был год напряженной работы. Исправлены ошибки, изменены мелочи, добавлены мелочи. В конечном итоге система была готова выдерживать реальную производственную нагрузку, и кодовая база выросла. На этом этапе команда AM получает запрос на добавление новой большой функции.
И мы возвращаемся к первоначальному вопросу. Легче ли было добавить новую функцию сейчас или было проще добавить новую функцию, когда мы были в режиме проекта?
Ответ очевиден: задача для команды AM намного сложнее. Это правда, что команда AM опирается на опыт, накопленный с течением времени, но в то же время команде AM необходимо серьезно коснуться не очень стабильной кодовой базы, необходимо избегать введения регрессий, не имея приличной системы безопасности при тестировании, необходимо разработать способ развертывания новой основной версии без нарушения работы.
Скажем так. Команда AM часто сталкивается с гораздо более сложной работой, чем команда Project. Так почему же, если задача AM-команды сложнее, большинство, если не все старшие люди были в команде Project и теперь находятся где-то в другом месте, вероятно, занимаясь чем-то еще классным?
Возможный ответ: команде проекта необходимо заложить правильный фундамент.
Одна из причин, по которой самые опытные люди начинают проект, заключается в том, что вначале нам нужно заложить фундамент для того, что должно произойти. Нам необходимо определить архитектуру и принять некоторые фундаментальные решения о дизайне решения, поэтому необходим правильный опыт.
В то же время в начале проекта у нас обычно только ограниченные знания о проблеме, которую мы призваны решить. В начале любого значительного проекта есть много известных неизвестных, а также много неизвестных неизвестных. По этой причине Архитектуру системы всегда следует рассматривать как эволюционную, и мы должны осознавать, что многие важные решения не могут быть приняты вначале, но должны быть приняты, когда неизвестное начинает проявляться.
Рассмотрение архитектурных решений как вещей, которые нужно решить раз и навсегда в начале проекта, часто является иллюзией. Критические архитектурные вопросы могут возникнуть в любой момент в жизни системы ЕО. Критические архитектурные решения, принятые в начале проекта, возможно, придется пересмотреть позже, возможно, из-за новых требований, может быть, из-за появления новых технологий, например Облако, может быть, потому, что они просто не подходили для решения проблемы.
Так что да, это правда, команда проекта должна принимать архитектурные решения, но также команда AM должна принимать архитектурные решения, и она должна принимать их в гораздо более сложной среде.
Вы просто не можете сделать обратное
Хотя классическая модель сильной проектной команды, за которой следует более младшая команда AM, не является самой эффективной в среднесрочной перспективе, обратное тоже не является ответом. Мы не можем себе представить, чтобы младшая команда начала проект, а затем передала его более старшей команде для обслуживания, это явно не вариант.
Дело подсознания
Возможно, одна из веских причин, по которой более старшие люди начинают новые проекты с новыми крутыми технологиями, заключается в том, что им нравится начинать что-то новое с новыми крутыми технологиями, а затем со временем, когда работа становится более повторяющейся, они просто хотят перейти к другим задачам. .
Это хорошо для их технического любопытства и для их резюме. Но это, вероятно, плохо сказывается на долгосрочном здоровье создаваемой ими ЕО системы.
От команды проекта к команде продукта
В 2006 году технический директор Amazon Вернер Фогельс придумал знаменитый девиз вы строите, вы запускаете, чтобы передать идею о том, что команда, отвечающая за продукт, должна обслуживать его с момента его создания до этапа выполнения, где выполнение охватывает как аспекты операций, так и аспекты эволюции. Проще говоря, одна и та же команда отвечает за все этапы, необходимые для успеха продукта: проектирование, сборка, запуск, развитие. Эту модель приняли цифровые гиганты, появившиеся за последнее десятилетие, от Amazon до Facebook и AirB&B. Их бесспорный успех является доказательством того, что эта модель является правильной в цифровую эпоху.
В настоящее время все больше людей начинают предсказывать необходимость перехода от ориентированного на проекты способа организации работы к модели, ориентированной на продукт. Это сложная трансформация, которая включает в себя многие аспекты организации, но для обсуждаемой здесь темы это определенно означает отказ от идеи разделения команд Project и AM и создание более стабильных команд по продуктам. В продуктовых командах должно быть правильное сочетание опытных людей и более молодых людей, которым необходимо расти. Работая вместе со старшими, юниоры постепенно и сами становятся крутыми. Тогда возможна контролируемая ротация без ущерба для качества команды.
Заключение
В эпоху, в которой мы живем, в эпоху цифровых технологий, мы должны быть подозрительными, когда слышим что-то вроде «и когда проект закончится, мы перейдем на AM».
Это не означает, что для AM больше нет места. По-прежнему существуют старые устаревшие системы, обычно обслуживающие бэк-офис, которые вопиюще выполняют свою работу, очень стабильны и требуют лишь некоторого обслуживания.
Но когда дело доходит до разработки новых дифференцирующих цифровых возможностей, нам необходимо отойти от модели Project / AM и принять модель, ориентированную на продукт, в которой команды призваны нести ответственность не только за создание первой версии продукта, но и за ее запуск. , чтобы научиться его запускать, развивать его с течением времени, чтобы убедиться, что он остается актуальным для конечных пользователей.
