IT для неайтишников: Какими бывают IT-шники? Часть 6

Периодически мне задают вопрос: "Кто есть кто в мире ИТ?". Вопрос этот интересный и объёмный. Чтобы не рассказывать всё по много раз, я напишу несколько статей и буду на них ссылаться. Шестая часть статьи посвящена людям, которые руководят проектами и продуктами. Заодно попробуем понять, чем проект отличается от продукта и почему процессы их управления сильно отличаются.

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи МегаБокс/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом) .

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

В первой части мы составили примерный список IT-специалистов, который хотим рассмотреть, список получился объёмным, но на полноту не претендующим. Затем мы рассмотрели эникейщиков, специалистов технической поддержки второй и третьей линии, системных администраторов (первая часть), программистов, поняли, чем младшие (junior), средние (middle) и старшие (senior) специалисты отличаются друг от друга (вторая часть), руководителей технической поддержки, технических лидеров и лидеров команд разработки (третья часть), специалистов по тестированию (QC), специалистов по обеспечению качества (QA), и DevOps-специалистов (четвертая часть), бизнес-аналитиков, UI/UX-специалистов, системных аналитиков (пятая часть).

В шестой части мы рассматриваем людей, которые занимаются процессом управления изменениями, кто-то через реализацию проектов, кто-то через развитие продуктов. Для того чтобы лучше понять различия между этими двумя специализациями, будет необходимо понять, чем проект отличается от продукта. Кроме того, разберём очень интересный вопрос вида: «Agile» vs «Waterfall». Здесь слово «Agile» умышленно взято в кавычки, так как к настоящему Agile оно имеет опосредованное отношение. Плюс ко всему рассмотрим некоторые модели разработки программного обеспечения.

От квалификации руководителя проекта и руководителя продукта часто зависит, станут ли вообще необходимые/запланированные изменения доступны конечным пользователям. Рассмотрим для начала с чем им приходится работать.

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

Когда мы разрабатываем проект, то работаем с зафиксированным объёмом требований, внесение изменений в который нужно согласовывать. Вместе с требованиями у нас ограничены либо зафиксированы сроки и бюджет на реализацию проекта.

Когда мы разрабатываем продукт, то зафиксированного объёма требований у нас нет. Вместо этого у нас есть метрики (показатели) продукта, которые мы должны достигать и улучшать. Например, это может быть количество посещений сайта, количество обрабатываемых заявок либо заказов и т.д. Для достижения метрик мы проверяем гипотезы, то есть внедряем какие-то изменения и замеряем результат. Разработка (развитие) продукта - это постоянный процесс, поэтому мы не имеем ограничений по срокам. То есть мы ограничены лишь бюджетом на развитие продукта и целями по достижению метрик продукта.

При этом развитие продукта может представлять из себя последовательность проектов. А реализация проекта может подразумевать изменение сразу нескольких продуктов.

Таким образом понятия проекта и продукта настолько же разные, насколько они похожие. Следовательно, процессы управления разработкой проекта и разработкой продукта будут столь же похожи, насколько являться разными. Именно из-за этого возникает много проблем и недопонимания.

Вообще в противопоставлении «Agile», то есть гибких методологий, и «Waterfall» (водопад), то есть каскадной модели разработки, прекрасно решительно всё. Потому, что это сравнение манифеста (Agile Manifesto), который не является ни моделью разработки, ни методологией, с моделью разработки, которой «не существует».

К сожалению, на курсах экспресс-обучения руководителей проектов/продуктов от онлайн-школ об этом не рассказывают. И когда начинаешь спрашивать кандидатов на собеседованиях про смысл и историю вопроса, многие начинают заметно плыть. Вопрос противостояния «рыцарей Agile» хтоническому чудовищу «Waterfall» уже несколько поднадоел.

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

В 1970 году доктор Winston W. Royce опубликовал статью «Managing the development of large software systems», в которой для обоснования преимуществ итеративной модели разработки привёл пример наивного подхода к управлению разработки, который потом назовут каскадной моделью (Waterfall, водопад). В 1976 году T. E. Bell и T. A. Thayer в своей статье «Software requirements: Are they really a problem?» уже называли описанный Ройсом наивный подход, как «Waterfall» (страница 62, если кому интересно).

В заключении своей статьи Ройс напишет, что, исходя из его опыта, описанный им наивный подход никогда не работает при разработке больших систем. А в самой статье продемонстрирует, как перейти от наивного подхода к итеративной модели разработки. То есть к модели разработки, на которой основана популярная методология Scrum (хотя он и позиционируется не как методология, а как фреймворк) из семейства Agile. Часто Scrum вообще путают с Agile, хотя это очень разные вещи.

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

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

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

Итеративная модель разработки предполагает внесение доработок короткими итерациями с использованием цикла «Планирование — Реализация — Проверка — Корректировка» (PDCA: Plan-Do-Check-Act), иначе говоря - цикла Деминга, известного из процессов управления качеством. В простом случае каждая итерация — это небольшой проект по доработке, включающий в себя сбор, анализ и формализацию требований, разработку, тестирование и внедрение. В более сложных случаях итерации идут «внахлёст», то есть пока идёт реализация текущей итерации, ведётся проработка требований к последующей итерации. Таким образом получается непрерывный поток анализа пользовательского опыта, требований, их формализация и постановка задач на следующие итерации, а так же непрерывный поток разработки, отладки и тестирования.

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

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

В целом не надо изобретать велосипед, можно просто взять Scrum, который неплохо проработан и описан. Собственно, именно это пробуют сделать многие продуктовые команды разработки, хотя иногда без помощи консультанта по Agile всё равно не обойтись.

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

Модель даёт возможность разделить изначально большую систему на набор сравнительно небольших модулей, которые можно разрабатывать последовательно либо параллельно (если повезёт). За счёт небольшого размера модуля, снижается его сложность, поэтому его легче проектировать, реализовывать и тестировать.

Иногда инкрементный подход неверно называют «мульти-водопад». С наивной моделью разработки, которую когда-то описал Ройс, инкрементная модель имеет немного общего. В ней уже используются развитые механизмы управления рисками и неопределённостью. И кроме того, происходит поэтапная контролируемая и запланированная поставка ценности бизнесу.

Инкрементная модель позволяет вам реализовывать системы, требования к которым вы себе представляете нечётко. То есть вроде понятно, что и где «в целом» должно быть, но система настолько большая и сложная, что описать её целиком не получается.

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

Потому что в первом случае перегрузка от резкого манёвра будет принята командой, в которой много людей, а во втором случае всего одним человеком. Риски того, что команда разом сгорит под нагрузкой меньше, чем риски того, что сгорит один человек. Хотя есть нюансы и опции.

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

Именно на инкрементно-итеративной модели разработки основаны самые мощные методологии ведения проектов, например Unified Process (UP), которые по гибкости и манёвренности превосходят итеративную модель разработки, при этом сохраняя надёжность и предсказуемость инкрементного подхода.

Просто для понимания, ядро Unified Process было опубликовано в 1995 году, Rational Unified Process увидел свет в 1998 году, а Agile Manifesto появился только в 2001 году. Методология Scrum была впервые описана в 1995 году. То есть UP и Scrum - это ровесники, которые появились ещё до Agile. Кроме того есть несколько адаптаций UP под Agile, например Agile Unified Process (AUP). Ну как адаптаций, просто выкинули половину из методологии...

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

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

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

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

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

У руководителя продукта есть метрики, которые он должен достичь либо которые он должен улучшить. Для этого руководитель продукта придумывает гипотезы, отбирает какие-то из них и проверяет их на продуктиве (версия продукта, доступная конечным пользователям). Для проверки гипотез команда разработки производит какие-то доработки и осуществляет их внедрение. Если гипотеза подтвердилась и метрики улучшились, то гипотезу начинают развивать. Если нет, то берут следующую гипотезу.

Это процесс непрерывного улучшения, то есть команда разработки загружена непрерывным потоком задач. Часто для продуктовой разработки используют Scrum либо Kanban. Под Kanban сейчас могут понимать как самые примитивные методы потоковой разработки, так и подходы на базе Lean.

Тем не менее с какой-то ритмичностью на продуктив попадают доработки, которые должны нести в себе бизнес-ценность. С точки зрения Scrum — это поставка ценности на продуктив. В Scrum нет ограничения на сроки и объёмы работ, есть только цели и бюджет. В целом, как и у продуктов.

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

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

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

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

Хорошим руководителем проекта может быть только человек, который умеет заканчивать. Есть проекты, которые готовы на 95%, но доработка последних 5% занимает вечность. Есть проекты, которые не могут сдвинуться с начальной стадии. Без умения заканчивать и без желания увидеть конечный результат своей работы руководителем проекта лучше не становиться.

Руководитель проекта должен быть основной движущей силой проекта. Это сложная роль, требующая высокой степени самоотдачи.

В шестой части мы поняли, чем отличается продукт от проекта, какие модели разработки программного обеспечения используются для проектов, а какие для продуктов. Немного коснулись маркетингового противостояния «Agile» и «Waterfall» и поняли, что этому вопросу уже больше 50 лет. В конце мы рассмотрели специализации руководителя продукта и руководителя проекта.

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

Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.

Полезные материалы по теме:

• IT для неайтишников: Зачем оно нужно?
• IT для неайтишников: Какими бывают IT-шники? Часть 1
• IT для неайтишников: Какими бывают IT-шники? Часть 2
• IT для неайтишников: Какими бывают IT-шники? Часть 3
• IT для неайтишников: Какими бывают IT-шники? Часть 4
• IT для неайтишников: Какими бывают IT-шники? Часть 5
• IT для неайтишников: Какими бывают IT-шники? Часть 6
• IT для неайтишников: Какими бывают IT-шники? Часть 7
• IT для неайтишников: Какими бывают IT-шники? Часть 8
• IT для неайтишников: Куда исчезают программисты после 40 лет?
• IT для неайтишников: Срывают сроки, что делать бизнес-заказчику?
• IT для неайтишников: Технический долг или почему теперь всё так долго?
• IT для неайтишников: Осторожно - JSDD (Бизнес в заложниках у IT)
• IT для неайтишников: Инженеры в заложниках у бизнеса
• IT для неайтишников: Потеряли ключи от IT, что делать?
• Как писать код, чтобы тебя не уволили? (про JSDD — Job Safety Driven Development)
• Процессы в ИТ: Долго, дорого и не то
• Саморегуляция в ИТ: минимально допустимая эффективность работы
• Telegram-канал Записки ITBP (короткие сообщения)
• Канал на Дзен Записки ITBP (статьи среднего размера)