Руководство над разработкой

Привет! Меня зовут Наташа, я руковожу разработкой бэкенда страницы yandex.ru. Сейчас у нас в команде больше двадцати человек, которые входят в отдельные группы разработки. Три года назад я впервые стала «тимлидом» маленькой группы из четырёх человек, накопив к этому времени десяток лет опыта в разработке и эксплуатации. Я не стесняюсь сказать, что переход от разработчика к тимлиду дался мне тяжело — и это нормально!

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

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

1. Введение

Итак, начнём. Есть фундаментальная проблема роста из специалиста в руководителя. Сразу же заменю здесь слово «рост» на более точное слово «трансформация», потому что никакого роста как раз не происходит.

Как обычно представляют себе этот «рост»

Как всё работает на самом деле

Тут должно стать понятнее, почему это трансформация: потому что это смена одного направления на другое.

^{Почему так}

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

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

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

Какие неочевидные штуки начинают происходить

Самая первая проблема, с которой сталкиваются молодые руководители, — отрицание новой реальности. Реальность проявляется в том, что старые модели поведения перестают работать, а человек начинает испытывать нарастающее напряжение, потому что пытается играть новую роль старыми способами. Это приводит к конфликту: «Вроде бы я всё делаю правильно, но что-то не так». А конфликт, в свою очередь, приводит к увеличению усилий и к росту внутреннего напряжения.

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

^{Скиллы-бонусы => скиллы для выживания}

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

^{Копать золотой лопатой}

Допустим, наш разработчик — это копатель ямок. Его назначают на должность руководителя, и он продолжает копать те же самые ямки. Назову это «копать золотой лопатой»: результат тот же — выкопанная ямка, но за больший бюджет. В чём смысл? Ни в чём, его нет. На практике дела обстоят хуже. Наш новый руководитель начинает ходить на разные встречи, заниматься командой и много отвлекаться, поэтому для выкапывания выбирает несложные ямки, не лежащие на критическом пути, или совсем никому не интересные ямки, потому что интересные он отдал своим любимым копателям для поддержания мотивации. В общем, золотая лопата используется для неважных ямок.

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

^{Играющий тренер}

Ещё одна проблема при попытках совмещать разработку и управление в том, что приоритет руководителя — управлять. А пока человек не стал руководителем, он был классным разработчиком. Что его сделало таким? Правильно — любовь к своей профессии. Что будет происходить с нормальным человеком, занимающимся любимым делом, когда его отвлекают на всякие непонятные управленческие дела? Он начнёт прятаться от окружающих и избегать того момента, когда надо перестать делать любимое дело, особенно если «там чуть-чуть осталось» и сладкая победа так близка. В общем, он будет копать своей золотой лопатой подальше от чужих глаз, чтобы ничто не отвлекало его от прекрасного состояния потока.

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

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

^{Состояние потока}

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

^{Очень много операционки}

Очень-очень-очень много операционки. Что такое операционка? Это регулярно повторяющиеся однообразные действия, производимые для поддержания работы системы. То есть это выполнение операций. У них что-то на входе, что-то на выходе, но принципиально в системе ничего не меняется.

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

Как обычно выглядит состояние руководителя

Как оно должно выглядеть

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

^{Время = энергия и лимит принятия решений}

Распределение времени — одна из первых проблем, с которыми я столкнулась. Я долго не понимала, что происходит: казалось, что я внезапно очень сильно постарела, заболела или произошло ещё что-то плохое, потому что каждый вечер я чувствовала невероятную усталость. А вот что произошло: будучи разработчиком и находясь в потоке, я часто могла заниматься своей задачей по десять-двенадцать часов в день, потом ещё на выходных хватало сил на пет-проджекты, и всё было прекрасно. Откуда-то у меня было убеждение, что раз можно программировать по десять часов, то можно и ходить на встречи по десять часов. Но это не так. Программирование — это примерно 20% анализа задачи и выработки решения и ещё 80% её реализации и придумывания воркэраундов для суровой реальности. То есть час на принятие сложных решений и четыре часа на их реализацию в более или менее комфортном темпе.

Когда ты ставишь двенадцать встреч в день по 30 минут, то выходит шесть часов принятия сложных решений в условиях очень ограниченного времени при полной смене контекста. Встречи начинаются в 10:00, заканчиваются в 16:30 (обедаю где-то по дороге), и я сижу и думаю, почему хочется умереть — ведь рабочий день в разгаре и у меня ещё столько планов, я же совсем немного поработала. В общем, количество времени, затраченного на работу, никак не связано с количеством израсходованной энергии. Как выяснилось, она не бесконечна. Можно случайно перегнуть, и тогда восстановиться бывает очень сложно. Наблюдайте за собой и контролируйте состояние, чтобы не допустить выгорания.

^{Цикл обратной связи}

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

^{Авторитет эксперта}

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

^{Потеря цели}

Что происходит: у нас был классный разработчик, понимавший, как он будет развиваться, планировавший изучить machine learning, коммитить в ядро Linux, придумывать свои алгоритмы. Потом к нему пришли и сказали: «Ты такой классный разработчик, мы решили, что теперь ты будешь руководителем. Ты молодец!»

Что происходит в голове у нашего героя: «Вау, это доказательство того, что я крут, я расту!» Примерно это, хотя тут куча вариаций.

Что происходит на самом деле: у нашего крутого разработчика теперь другое будущее — будущее руководителя. Если вовремя не понять этого, то получится тот же разработчик с амбициозными планами про machine learning, занимающий руководящую позицию. Пока не наступит принятие всех пунктов выше и не сформируется понятная картина будущего, будут страдания и боль — если не у молодого руководителя, то у команды или у руководителя этого руководителя. В общем, у кого-то обязательно будут.

^{А что я буду делать, если раздам все зоны ответственности и перестану гонять на поле?}

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

Какие знания даёт типичный курс начинающего руководителя

Есть множество курсов для начинающих руководителей. Отлично, что они вообще существуют. Там учат ставить задачи по SMART, делегировать и давать обратную связь.

Где эти знания находятся, по мнению большинства (я тоже думала, что здесь)

Где они находятся на самом деле

Суровая правда: курс учит, как делать, но не учит, что делать.

Когда наступает хоть какое-то чувство комфорта

Большинство компаний ведёт упорядоченный образ жизни и живёт циклами. Циклом может быть проект или какая-то внутренняя жизнь компании, например, полугодовое планирование. Если вы не знаете об этих циклах — это не значит, что их не существует. Лучше сразу выяснить, что это за циклы, и выстраивать свою работу в синергии с ними.

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

Когда на самом деле начинается рост

Настоящий рост руководителя начнётся, когда:

1. Он научится стабильно работать в новой реальности, справляться со своими минимальными обязанностями и при этом не думать каждый день, что всё плохо и непонятно. Это стадия принятия и экономии энергии.
2. У него появится ясная картина собственного будущего в области управления, превосходящая его текущие возможности. Это стадия выхода из ямы, ощущение уверенности в выбранном пути.
3. Появится постоянное желание менять старое и привносить новое. Это стадия идей и генерации энергии.

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

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

2. Целевое состояние

Задача первого этапа трансформации — создать образ руководителя, которому нужно и хочется соответствовать.

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

Попробуйте начать с текстового описания своего образа: возьмите ручку, бумагу и ответьте на вопросы:

— Чем мне нужно заниматься на самом деле?
— Каким я хочу быть в роли руководителя?
— Как я хочу чувствовать себя в роли руководителя?

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

Затем опишите критерии, по которым будете оценивать, двигаетесь ли вы в нужную сторону. Например, они могут быть такими:

— Я перестала работать по двенадцать часов.
— Мне больше не звонят ночью.
— Команда выполнила запланированные проекты.
— Мы наняли трёх новых сотрудников (а старые не ушли).
— …

Тут может быть что угодно: всё зависит от конкретной ситуации.

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

3. Движение

В этой части будет два рецепта по движению к целевому состоянию:

— Анализ текущих усилий
— Преодоление оставшегося беспокойства

Анализ текущих усилий

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

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

^{Таблица}

Нужно нарисовать вот такую таблицу:

Деятельность: сюда пишем все виды деятельности, которыми вы обычно занимаетесь. Например, код-ревью, распределение задач, встречи с руководством, найм, управление проектом Х, выполнение задач руками, планирование ресурсов. Даже разные виды встреч — это разная по смыслу активность. Когда я первый раз заполнила такую таблицу, у меня получилось 30+ видов деятельности. Если у вас получилось десять, то надо напрячься и думать дальше. Если отнестись к этому аккуратно, то в сумме получится примерно столько времени, сколько вы реально тратите на работу.

Функция: здесь нужно честно ответить себе на вопрос, в какой роли вы выступаете, делая эту работу. Является ли это работой того руководителя, образ которого вы себе нарисовали? Также можно писать комментарии о цели работы. Например: «Руководитель — поддержка морального духа». Или: «Специалист — проверка качества работы». Вот тут как раз пригодится напарник, который будет задавать вопросы, почему это делаете именно вы, точно ли это должны делать именно вы. Для одного вида деятельности может быть несколько функций, так что не торопитесь и прислушайтесь к себе.

Как часто, сколько занимает: оцените частоту выполнения этой работы и сколько времени она требует. Например, два часа раз в месяц, 30 минут раз в день и так далее. Даже две недели два раза в год — хороший ответ.

Сколько это в неделю: нужно пересчитать всё, что написано в предыдущей колонке, в количество часов в неделю.

Тут ждёт первый бонус: сумма общего времени, затрачиваемого на работу. Если она получилась подозрительно меньше, чем вы на самом деле работаете, то вернитесь к первому пункту и вспоминайте, чем ещё занимаетесь. Первый раз у меня вышло 50+ часов — даже без учёта того, что надо ещё обедать, делать перерывы и что бывают всякие внезапные вещи. Именно в тот момент я перестала удивляться, почему работа всё время переезжает на выходные, а мой календарь выглядит как апокалипсис эффективности. Тогда я ещё пыталась улучшать инструменты для повышения личной эффективности, но проблема была в другом — в отсутствии чёткого представления о работе руководителя.

Это мне нужно делать на самом деле: колонка, в которой вы проставляете «да»/«нет». Если совсем тяжело, то можно выбирать вариант «частично».

Что с этим сделать: и тут самое интересное. Придумайте, что сделать с теми вещами, которыми заниматься не нужно или нужно частично. Так вы перестанете тратить на них столько времени. Всё зависит от конкретной ситуации. Можно передать эти задачи кому-то другому, делегировать человеку «на вырост», перестать делать вообще, упростить, автоматизировать, поделить и раздать команде и так далее.

^{Пожинаем плоды}

Все строки таблицы нужно раскрасить в красный, жёлтый и зелёный цвет.

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

Получится что-то в таком роде:

Теперь с опустошённым сознанием посмотрите на таблицу. Ну как?

И бонус номер два: для всех красных и жёлтых видов деятельности посчитайте сумму часов в неделю, которая освободится, если воплотить в жизнь все решения из колонки «что с этим сделать». Как вам результат? Если получилось 0, то вы себя обманываете.

^{Что делать дальше}

Выберите из последней колонки то, что вы сделаете в течение следующего месяца. Через месяц вернитесь и актуализируйте таблицу (вычеркните те виды деятельности, которыми вы перестали заниматься), уточните затраты по времени, выберите новые действия на следующий месяц. Если всё выполняете правильно, то через три месяца вы освободите себе достаточно времени, чтобы начинать заниматься новыми направлениями из вашего целевого состояния.

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

Преодоление оставшегося беспокойства

Рецепт на тот случай, когда мучает ощущение, что ещё есть задачи, которыми нужно заниматься, но сейчас на них нет достаточного ресурса. Вы сможете за них взяться, когда воплотите в жизнь всё придуманное в предыдущем упражнении. Но пока этот момент не наступил, можно создать mind map.

Нарисуйте в центре вопрос: «Что меня беспокоит?».

И честно выписывайте всё, чем, по вашему мнению, нужно или хочется ещё заниматься.

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

Затем у каждого пункта честно напишите, есть ли необходимость делать это прямо сейчас. Например: «делать», «отложить до Х», «не делать» или ещё какие-то варианты на ваш вкус.
Те пункты, где вы решили ничего не делать, можно просто выбросить из головы и перестать о них беспокоиться, ведь решение уже принято.

Для пунктов, где написано «делать», придумайте минимальные усилия, которые будут давать хотя бы небольшой результат, но при этом не потребуют много ресурсов. Например: «поставить встречу с Х раз в неделю», «читать одну статью по теме в неделю» и так далее.

Получится что-то такое (все совпадения случайны, картинка выдуманная):

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

4. Финальная часть

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

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

Задача управления

Основная задача управления — достижение целей за счёт сознательных усилий. Здесь два ключевых слова: цель и сознание.

(Отдельно замечу, что отказ от достижения цели — это тоже достижение цели, но другой — находящейся уровнем выше.)

Задача руководителя

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

Что делать, если я до сих пор не знаю, что делать?

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

Что делать, если мне слишком тяжело

Возьмите паузу и примите наконец это решение: откажитесь от роста в управленческой ветке. Спросите себя: «Зачем мне это?» Если нет хорошего ответа, от которого наступает успокоение и тепло разливается по телу, примите другой хороший ответ: «Это не для меня, и это нормально». Можно быть уникальным специалистом с невероятной экспертизой, и мир будет счастлив, что вы у него есть, а вы будете счастливы, что сами приняли правильное решение.

Пять секунд мотивации

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

Реальный опыт

Всё описанное выше — мой опыт и пройденный путь. Было ли сложно? Конечно. Самое сложное — продолжать делать, пока не получится, несмотря на регулярно посещавшие мысли, что мне это просто не дано. Можно ли быть счастливым руководителем? Точно можно.

�����: ����������� ����������� � ��� ����������

����� 6

����������� ����������� ������������ �����������

��� ����� ��������� �������� ����� ��������� ����� ����� ��������, ����������� �� ���������� ��������� ������ �������� ����������. �������� ��������� ���, ��� ������ �������� ��������������� � ������ ������ �������� ���������� �������������. ��� ��� �������� ���������� ���������, ���� ������������ ���������� ����������������. ��������� �� ��� ���������� �� ������ ������� ���������� �������, ��������� �������. ��������� ���� ������� ��������� ��� �� ����������� �����, ������ ������ �������. ����� ����������� ������ �� ��� ����� ���������� ����� ��������, ��, ������, ����� �� �������� �� ����.

������� ���������� �� ��������� �������� �� ��������� �������� � �����������, ��� �� ��� ��������� ����������� �� ���������� ����������� �������� �������. �� ��������� ��������� ���� ����� ��������� � ��� ������ ���������� �������� ������ ������������� ������������. ������� ��, �� ������� ������� � �� ����� ���������� ������ ������������ �����������. �� ������� ����������� �������� � ������ �����������, ����� �������� ���������� ����������� ����������� ������������ �����������; ��� ������ � ����������� ��������, �������� �� ����� ���������� ������� ������� � �������� ������������ ����������� ������������ �����������. � ���� � ��������� ������ �� ������������� ���� �������� �� ��������, �������� ��� ������� ����������� ������������ ���������� ��������� �������. �� ���������, ��� ���� ������������ ������ �������������; ��� ������� ������������ ����������� ������������ �����������; ����� ������� ����������, ������������� �� ����������� ����� ��� ���������� ��� �� �������; ����� ������� ��������� ����������. �� ����������� ������ ��������� �����, � ������� ������� ����������� � �������, � ����� �����, ������� ������������ ������� ��������� � ������.

�� ��� ���� �������� ������ ��������? �� ��� ���������� ���� ������? ��� �������� ���� �����? ����� ������� �������� ������������?

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

Генрик Мкртчян — сооснователь и генеральный директор агентства веб-разработки «Кодеры», рассказал, как под ключ организовать процесс разработки в компании: от постановки задач до релиза продукта.

У нас есть два основных принципа:

1. Команда делает проекты качественно, в срок и с прибылью для компании;
2. Большинство решений, связанных с реализацией проектов, команда принимает самостоятельно, так как основные процессы в компании автоматизированы и прозрачны.

Проект любого масштаба мы разделяем на семь обязательных этапов.

1. Выбираем методологию

От этого зависит состав команды, порядок и даже график работы. Можно выбрать классическую (waterfall) или гибкую (agile). 

При классической методологии:

Команда будет работать строго по ТЗ. Результат, который вы получите в итоге, будет ровно таким, каким вы его запланировали в самом начале.

При гибкой методологии:

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

Если вам нужно быстро запустить MVP-версию продукта и понять, в каком направлении его развивать – выбирайте гибкую методологию.

2. Определяем роли и состав команды

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

Классический отдел разработки состоит из следующих сотрудников:

• менеджер проекта: контролирует рабочий процесс, дедлайны, оптимизирует работу сотрудников;
• архитектор: определяет стек технологий, проектирует общую инфраструктуру проекта, его основные компоненты, модули и сервисы;

• frontend- и backend-разработчик/fullstack-разработчик: первые занимаются визуальной и вычислительной частью проекта, а второй, как универсальный солдат, владеет знаниями разных технологий;

• тестировщик: обеспечивает качество программного продукта с самого начала разработки и до его финальной сдачи;

• тимлид: декомпозирует и делегирует задачи, проводит код-ревью и поддерживает боевой дух команды;

• дизайнер: определяет внешний вид продукта, его интерфейс и юзабилити;

• аналитик: проектирует и оптимизирует процессы, руководит внедрением новых IT-систем и адаптирует систему работы к новым задачам;

• системный администратор: осуществляет бесперебойную работу серверов, настраивает площадки для разработчиков и обеспечивает техническую инфраструктуру.

В некоторых из них нет необходимости, если проект небольшой – например, в архитекторе или аналитике. Главное: берите профессионалов, на которых сможете положиться и которые в состоянии принять решение по специфичным вопросам. 

3. Проводим CustDev, собираем требования с клиентов, пишем техническое задание

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

Уделите внимание техническому заданию. ТЗ – гарант, что вы не потратите время зря, не переплатите и получите нужный результат. Кроме того, оно обеспечивает техническое развитие продукта и поможет:

• оценить задачу по бюджету, срокам и объему человеко-часов;
• упростить сдачу-приемку проекта;
• объяснить специалисту, как устроена работа проекта и какую документацию нужно готовить «на выходе».

4. Обеспечиваем команду техническими инструментами

За настройку технической инфраструктуры отвечает системный администратор. Строить боевую инфраструктуру сразу не обязательно – выполните минимальную часть, чтобы обеспечить команде место для работы. 

Настройте:

• репозиторий для кодовой базы проекта;
• общие инструменты организации процесса разработки, если они нужны – например, таск-трекер (Jira, Redmine, Trello и другие);
• рабочее окружение: сервисы и приложения, от которых будет зависеть ваш продукт (например, Swagger для документации API).

Убедитесь, что у всех членов команды имеется доступ к инструментам разработки и рабочему окружению.

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

---

Читайте также:
Разработка мобильного приложения: как создать прототип и зачем нужен MVP
Кроссплатформенная и нативная разработка мобильных приложений в 2021 году
12 шагов к успешному запуску детского приложения

---

5. Планируем работу команды

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

Составляя график, учитывайте сдвиг сроков задач (например, увеличение сроков из-за исправлений ошибок) и продумайте, как одна задача зависит от другой.

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

Понятие разработки программного обеспечения

В первую очередь, необходимо дать определение понятию разработки программного обеспечения.

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

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

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

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

Методы структурного анализа для проектирования ПО

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

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

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

• У каждого «черного ящика» должна быть одна единственная функция.
• Функции этих «ящиков» должны быть просты для понимания, даже если их сложно реализовать на практике.
• Взаимосвязь между элементами системы должна создаваться только в том случае, если взаимосвязаны их функции. Скажем, в бухгалтерии один из таких «черных ящиков» нужен для определения размера общей заработной платы работника, а другой — для определения размера налогов. Очевидно, что между ними должна быть связь. Ведь чтобы высчитать размер налогов, необходимо знать размер зарплаты.
• Любые взаимосвязи между «черными ящиками» должны быть максимально простыми. Благодаря этому они становятся независимыми друг от друга.

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

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

Скачать файл

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

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

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

Вместе с тем система все еще будет являться целостной, а все ее составляющие — связаны между собой. Если система разрабатывается «снизу-вверх» (от конкретных задач к общей системе), то утрачивается ее целостное представление. Кроме того, появляются трудности связанные с описанием информационного взаимодействия отдельных элементов.

В процессе структурного анализа и проектирования применяется множество моделей, которые описывают:

• функциональную структуру системы;
• последовательность производимых операций;
• передачу данных между функциональными процессами;
• отношения между данными.

Выделим несколько самых часто встречаемых моделей из первых трёх категорий:

• функциональная модель SADT (Structured Analysis and Design Technique);
• модель IDEF3;
• DFD (Data Flow Diagrams) — диаграммы потоков данных. Модель «сущность — связь» (ERM — Entity-Relationship Model), которая описывает отношения между данными. Обычно применяется в структурном анализе и проектировании. При этом она является подмножеством объектной модели предметной области.

Этапы разработки программного обеспечения

Первая стадия работы над ПО — подготовка

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

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

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

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

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

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

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

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

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

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

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

Следующий этап — опытная эксплуатация

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

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

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

Конечный этап любого проекта — завершение

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

Вспомогательные процессы при разработке ПО

В рамках разработки программного обеспечения можно выделить несколько вспомогательных процессов.

• Документирование. Исполнитель формирует документацию и руководства пользователя к создаваемому программному продукту, как во время разработки, так и после. Такие документы позволяют программистам разбираться в структуре и коде даже по прошествии длительного времени после их создания. При этом документация помогает пользователям взаимодействовать с системой.
• Управление конфигурацией. Речь идет о работах по управлению наборами создаваемых компонентов программного обеспечения, а также по управлению версиями программного продукта.
• Обеспечение качества. Данный процесс необходим для обеспечения соответствия ПП предварительным требованиям к разработке и нормам организации исполнителя и заказчика.
• Верификация. Позволяет обнаружить ошибки, которые были допущены при разработке ПО. Кроме того, благодаря верификации можно выявить несоответствия между разрабатываемым ПО и сформированной архитектурой.
• Аттестация. Она необходима для подтверждения соответствия получаемых величин принятым стандартам. Иными словами, выходные данные должны иметь погрешность, которая удовлетворяет всем требованиям и нормам.
• Совместная оценка. Данный процесс направлен на контроль и проверку состояния персонала и создаваемого ПП. Осуществляется заказчиком и исполнителем в течение всего проекта.
• Аудит. Необходим для независимой оценки текущей ситуации, характеристики проекта, документации и различных отчетов. Данный процесс позволяет сравнить реальное положение дел с договором и документами, в которых прописаны требования. Аудит может проводиться как одной, так и двумя сторонами.
• Разрешение проблем. Устраняются ошибки, которые были обнаружены на этапах контроля и оценки.

Факторы, влияющие на разработку ПО

Перечислим факторы, которые непосредственно влияют на результат разработки ПО:

• Классы решаемых задач. Определяют смысловое содержание создаваемых программ.
• Применяемые методологии. Они задают особенности организационного и технического выполнения базовых этапов создания ПО.
• Методы и парадигмы программирования. От них зависят стили кодирования и архитектуры виртуальных машин;
• Аппаратные и системные программные средства. Они являются виртуальными и физическими ресурсами, благодаря которым становится возможным применение ПО.

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

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

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

Специализированная модель необходима для описания конкретных параметров исследуемого явления. Она позволяет сосредоточиться на частных характеристиках.

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

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

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

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

Модели разработки программного обеспечения

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

Waterfall (каскадная модель, или «водопад»)

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

Преимущества:

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

Недостатки:

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

Waterfall предназначена для создания проектов в медицинской и космической сферах. В данных областях уже имеется крупная база данных (включая СНиПы и спецификации). Благодаря этим документам можно гораздо быстрее формировать требования к будущему продукту.

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

V-образная модель (разработка через тестирование)

Данную модель можно назвать улучшенной версией «водопада». Заказчик совместно с командой разработчиков формирует требования к системе и описывает, каким образом будет выполняться ее тестирование на каждой стадии. V-образную модель начали использовать в 1980-х.

Преимущества:

• Минимальное количество ошибок в архитектуре программного обеспечения.

Недостатки:

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

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

Incremental Model (инкрементная модель)

Английское слово increment можно перевести как «приращение». Данную модель начали использовать ещё в 1930-х. В качестве примера возьмём разработку социальной сети.

Заказчику необходимо создать соцсеть. Он сформировал подробное техзадание. Разработчики предложили сначала создать основные функции в виде страницы с личной информацией и чата. После этого будет проводиться тестирование на реальных пользователях.

Заказчик оценивает продукт и принимает решение о его выпуске. В том случае, если заказчик и пользователи довольны результатом, то дальнейшая работа осуществляется по частям.

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

Преимущества:

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

Недостатки:

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

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

Iterative Model (итеративная модель)

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

Преимущества:

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

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

Недостатки:

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

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

Spiral Model (спиральная модель)

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

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

Преимущества:

• Сосредоточение внимания на анализе рисков.

Недостатки:

• Вероятность того, что разработка слишком зациклится на самой начальной стадии.
• Повышенная стоимость и длительность разработки.

Гибкие подходы к разработке программного обеспечения

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

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

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

Преимущества:

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

Недостатки:

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

В рамках данного подхода применяется целый ряд всевозможных техник, методологий и приемов. Выделим некоторые из них:

• Scrum. Участники проекта находятся в постоянном взаимодействии и обсуждают текущий прогресс.
• Kanban. Используется виртуальная доска с задачами. Последовательность выполнения таких задач не определяется.
• RUP. Наличие четких стадий планирования, уточнения и построения новых итерация программного обеспечения.
• Extreme Programming. Частые обновления версии продукта и отыскивание наиболее скоростных решений.

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

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

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

Навыки и умения разработчика ПО

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

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

Такой специалист должен обладать следующими навыками:

• знание как минимум одного языка программирования;
• понимание принципов ООП, алгоритмом и структур данных;
• умение работать с ОС, сетевыми протоколами и методами обмена информацией по сети;
• владение инструментами тестирования и отладки кода.

Фрондендеру необходимо уметь:

• создавать динамичный, интерактивный интерфейс по макету;
• работать с деталями и знать нюансы поставленной задачи, чтобы обеспечить удобство эксплуатации продукта;
• использовать принципы адаптивной верстки. Это позволяет создать мультиплатформенный продукт.

Бэкендер выполняет следующие задачи:

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

Full stack представляет собой программиста широкого профиля. Он может выполнять все задачи связанные с созданием ПО, включая формирование клиентской и серверной части продукта. Ему необходимо обладать следующими умениями:

• знание нескольких языков программирования, распространенных библиотек и фреймворков;
• навыки работы в системе управления версиями Git, применение для сборки и развертывания приложения Docker или Kubernetes;
• понимание шаблонов проектирования и владение гибкими методологиями (скажем, Agile).

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

Есть много статей повествующих о каскадной, итеративной и других всеми любимых моделях разработки. Каждая из этих статей рассказывает о преимуществах и недостатках и предлагает читателю самому сделать правильный выбор в зависимости от проекта. Смешно то, что человеку, который будет принимать решение о модели и этапах разработки, скорее всего не нужно читать об этом статьи. Он и так все знает. С другой стороны “целевая аудитория” таких материалов сможет применить эти знания только через время (и то если сильно повезет). Поэтому предлагаю читателю прочитать не теорию из учебников, а послушать про реализацию на практике. Мы разберем про различия в подходах аутсорсинговых и продуктовых компаний. И чем различается взгляд на модель разработки с точки зрения заказчиков(работодателей) и разработчиков(сотрудников).

Джун на аутсорсе

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

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

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

Но этап Ревью нужен. Представим, что вам все таки попалась жизнеспособная компания, которая понимает важность соблюдения определенных правил разработки, поэтому после того как вы закончили свою задачу, создается merge request и ваш наставник начинает разбираться в том что вы натворили.

Скорее всего ваше первое ревью будет долгим, т.к вам потребуется не только исправить не только архитектурные и логические ошибки в вашем коде, но также и соблюсти code style (свод правил написания кода, специфичный для конкретной компании). Здесь самое главное чтобы ваш ревьювер не сильно увлёкся. У ревью можно выделить 2 главных назначения:

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

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

При этом очень важно сильно НЕ ударяться в перфекционизм. НЕ нужно по несколько дней вылизывать ваш код. Здесь нужно помнить о правиле “Лучшее враг хорошего”.

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

Как правило аутсорсинговые компании имеют отдельных тестировщиков. Это люди, которые не занимаются разработкой, а пытаются сломать вашу новую фичу, после чего приходят и говорят “чини”. И это хорошо, что есть такие люди. Т.к даже будучи разработчиком сложно найти уязвимости в своем коде. Отчасти потому что ты из всех сил пытаешься их не искать и не ломать код. Но даже если честно взглянуть на свой код, то очень сложно учесть все варианты взаимодействия пользователя (а их очень много).

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

Про автоматические тесты

Я не стал включать в главу про тестирование написание автоматических unit и интеграционных тестов. Поскольку считаю, что тесты — это не механизм проверки работоспособности вашего кода. Да конечно, есть TDD – но опять же, в этом случае вы с помощью тестов просто запускаете ваш код. Поэтому написание тестов нужно относить к этапу разработки.

Автоматические тесты – это в первую очередь защита от регрессии (поломки вашего кода) в будущем, т.к в момент написание тестов они точно будут работать (а тесты имеют смысл, только когда они перестают это делать).

Разработка, ревью, тестирование

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

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

От разработчика к менеджеру

Как правило, начинающие и разработчики среднего уровня не взаимодействуют напрямую с заказчиком, (но могут с командой разработки со стороны заказчика). Менеджерские функции выполняют Team-лиды, Product и Project менеджеры. Давайте рассмотрим чем отличаются эти 3 категории и чем они занимаются.

Team Lead, Product и Project менеджер

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

Отличие этих руководящих должностей в том, кто находится у них в подчинении. Схема следующая:

Product Manager -> Project manager -> Team Lead -> Разработчик

Естественно нужно понимать, что чем более “менеджерская” твоя должность тем более высокоуровневые задачи ты ставишь перед своими подчиненными.

Также, если вы захотите детальнее узнать про отличие этих должностей, то вероятно найдете, что-то из разряда Product менеджер решает ЧТО нужно разрабатывать, а Project менеджер КАК это разрабатывать. Но по большому счету это не является отличием, т.к в сухом остатке каждый получает некоторую задачу, которую он должен как то сделать. И само собой в ходе реализации будут заданы вопросы ЧТО, КАК и много других. Только заданы они будут к подзадачам, на которые разбивается исходная.

Какие задачи решают менеджеры

В качестве примера рассмотрим Team-лида, т.к почти каждая IT компания имеет в своем арсенале таких людей. Product и Project менеджеры все таки более редкие персонажи.

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

Первый этап – это обсуждение требований. Здесь вы выслушиваете хотелки клиента и с умным видом качаете головой, параллельно думая как можно реализовать тот или иной функционал. В ходе этого этапа вы должны определиться с “границами” в рамках которых ваша команда будет создавать новый проект. Какие технологии нужно использовать в разработке. Как будет отслеживаться прогресс. Список задач, которые нужно реализовать. Временные рамки. Первый контакт с заказчиком как правило происходит через письменные методы связи (мессенджеры, почта)

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

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

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

Также в рамках оценки проекта составляется команда, которая будет его реализовывать. При чем необязательно определится с конкретными людьми. Нужно лишь составить список из ролей. К примеру, 2 мидл разработчика, 1 старший, Тестировщик, Дизайнер и Team Lead. Естественно обговаривается сколько рабочих часов будет тратить каждый из специалистов и сколько стоит этот час. К примеру дизайнеры и тестировщики могут одновременно работать над несколькими проектами, а значит их вклад в текущий может быть только частичным (4 часа в день вместо 8).

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

В ходе распределения задач оценивается сложность каждой задачи, после чего эта задача попадает в Backlog (это список всех задач текущего проекта). Нужен он потому что нельзя сразу распределить задачи по разработчикам. Как правило, все IT компании работают по методологии Scrum или Agile.

В случае со Scrum каждые 2 недели(Спринт), из бэклога достается небольшой скоуп задач, которые распределяются между разработчиками. При этом если некоторые задачи не удается выполнить в текущем спринте, то они переносятся на следующий.

В случае с Agile, нет дробления на спринты. Разработчики берут задачи по мере выполнения. При этом нужно сказать, что почти во всех командах, есть некоторые промежуточные этапы в ходе которых анализируется сколько уже было сделано и сколько осталось.

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

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

А что же в Продуктовых компаниях

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

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

Работая в продуктовой компании у вас появятся моменты “Релизов” (когда выходит новая версия продукта). Такие релизы могут проходить раз в несколько месяцев или даже лет. Это время, когда проходит контрольное тестирование новой версии продукта, находится и исправляется большое число багов. Вы можете фиксить неисправности по несколько дней или недель (в зависимости от размера обновления). В какой-то степени — это можно сравнить с завершением проекта при работе с заказчиком (только ответственность за тестирование лежит полностью на вас).

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

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

Взгляд с позиции заказчика

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

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

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

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

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

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

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

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

Просмотр шаблона

Краткое содержание

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

Разработка нового продукта — это захватывающее, но сложное дело. Каждый новый продукт уникален на всех этапах от возникновения идеи до проработки и создания прототипа. Тем не менее, существует общий процесс, который поможет вам пройти этот путь наиболее эффективно. 

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

За последние годы процесс разработки продукта претерпел некоторые изменения. Сегодня он обычно применяется с разделением на шесть этапов. Это помогает более эффективно организовать сам процесс и разделить отдельные ожидаемые результаты на более мелкие задачи.  

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

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

1. Предложение идей

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

При разработке концепции нового продукта необходимо учитывать следующие факторы:

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

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

• Функциональность. Хотя подробные сведения о функционале продукта вам пока не нужны, необходимо иметь общее представление о том, какие функции он будет выполнять. Оцените эстетические аспекты своего продукта и подумайте, чем он может заинтересовать потенциальных покупателей.

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

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

В рамках утверждения концепции продукта идеи можно документировать в форме экономического обоснования. Так у всех сотрудников будет чёткое представление об исходных функциях нового продукта и целях его запуска на рынок. 

2. Определение продукта

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

На этом этапе важно определить следующие аспекты:

• Бизнес-анализ. Бизнес-анализ предусматривает составление стратегии распространения продукта, стратегии электронной торговли и более глубокий анализ конкурентов. Цель этого этапа — начать создавать чётко определённую дорожную карту продукта.

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

• Критерии успешности. Для того чтобы измерить и оценить успех запуска продукта, необходимо заранее чётко определить соответствующие критерии. Есть ли какие-либо ключевые показатели, на которые стоит обратить внимание? Это могут быть обычные КПЭ, такие как средняя сумма заказа, или что-то более конкретное вроде индивидуальных целей, актуальных для вашей организации. 

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

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

3. Разработка прототипа

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

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

На этапе подготовки прототипа прорабатываются следующие аспекты:

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

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

• Анализ осуществимости проекта. Следующим шагом в этом процессе является оценка стратегии по продукту с учётом результатов анализа осуществимости проекта. Определите, выполним ли предполагаемый объём работ в предварительно обозначенные сроки. Если нет, скорректируйте временные параметры соответствующим образом и обратитесь за помощью к заинтересованным сторонам.

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

Теперь самое время приступить к созданию дизайна продукта для его вывода на рынок. 

Попробовать ПО для управления рабочими процессами от Asana

4. Первоначальный дизайн

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

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

В рамках создания исходного дизайна выполняются следующие действия: 

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

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

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

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

5. Утверждение и тестирование

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

Для обеспечения высокого качества продукта выполните следующие действия:

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

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

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

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

6. Коммерциализация

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

К этому времени уже будет завершена работа над проектным решением и протестировано качество стратегии разработки и маркетинга. Вы должны быть полностью уверены в окончательной версии продукта и готовы к его производству. 

На этом этапе выполняются следующие работы:

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

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

Итак, ваш конечный продукт запущен. Вам остаётся только измерять успех с помощью сформулированных изначально критериев. 

Примеры процесса разработки продукта

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

Пример 1. Как компания Figma расширила функционал своего продукта

• Запущенный в 2012 году продукт Figma стал первым профессиональным инструментом для разработки пользовательских интерфейсов, работающим полностью в браузере. На сегодняшний день компания Figma занимает ведущее положение на рынке веб-приложений для дизайна.

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

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

Пример 2. Как компании Uber удалось занять нишу на рынке

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

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

Безусловно, каждая ситуация уникальна, однако при наличии правильной стратегии продукты вы также можете создать инновационный портфель. 

Кто входит в состав группы разработки продуктов?

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

К числу других важных участников процесса относятся:

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

• Менеджеры проектов. Менеджер проектов может участвовать в процессе разработки продукта, помогая обеспечивать обмен информацией между отделами. Он также занимается делегированием задач и отслеживанием целей.

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

• Разработчики. Специалисты по разработке помогают разместить продукт на вашем веб-сайте. Чаще всего группа разработчиков работает совместно над созданием нового продукта в зависимости от сложности концепции.

• Маркетологи. Специалисты по маркетингу участвуют в разработке маркетинговой стратегии и тестировании продукта до его вывода на рынок. Они также занимаются оценкой успешности маркетинговых инициатив.

• Отдел продаж. Менеджер по продукту совместно со специалистами по продажам разрабатывает эффективную стратегию и отчитывается о показателях успешности после реализации продукта. 

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

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

Читать о том, в чём разница между менеджером продуктов и менеджером проектов

Расширяйте свой портфель, разрабатывайте новые продукты

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

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

Попробовать Asana для управления продуктами

Содержание

Конкуренция на рынке постоянно растет: чтобы компания могла привлекать и удерживать клиентов, нужно подстраиваться под растущие требования аудитории, оперативно выполнять задачи и решать проблемы. Один из способов эффективно организовать работу внутри компании – проектный менеджмент. В статье расскажем, что такое управление проектами и как система помогает улучшить показатели бизнеса.

Что такое проект и его управление

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

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

Чем отличается проектное управление от традиционного менеджмента

Рассмотрим отличия разных систем управления наглядно.

Зачем нужно управление проектами

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

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

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

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

Стандарты управления проектами

Это рекомендации и советы, на которые нужно ориентироваться при организации работы. Какие стандарты бывают:

• Общественные. Разрабатывают и применяют в обществах специалистов.
• Корпоративные. Разрабатывают и используют в рамках одной компании.
• Частные. Создают специально для определенных проектов.

Есть международные стандарты управления проектами – правила организации работы в разных странах. Один из самых известных стандартов – PMBOK (A Guide to the Project Management Body of Knowledge). Это руководство по управлению проектами, где есть вся терминология и базовые принципы. Его применяют в более 160 странах мира.

Роли в проекте

Роль в проекте – это набор функций и полномочий для разделения обязанностей между членами команды. Стандарт PMBOK выделяет следующие роли:

• Заказчик. Утверждает требования и проверяет результаты, может изменить приоритеты.
• Спонсор. Согласовывает цели, бюджет и сроки работы, выделяет нужные ресурсы.
• Руководитель проекта. Распределяет обязанности в команде, контролирует соблюдение требований.

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

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

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

Кто такой руководитель проекта

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

Требования к проект-менеджеру

Какие компетенции понадобятся руководителю проектов в работе:

• Знания в области управления проектами, включая стратегическое мышление, умение прогнозировать и планировать.
• Опыт. Чем больше у проект-менеджера кейсов, тем лучше он понимает как распоряжаться бюджетом, решать разные проблемы, взаимодействовать с командой.
• Техническая подготовленность. Эффективный проект-менеджер – это не просто управленец, а компетентный специалист. Он может грамотно настроить все процессы, потому что разбирается в специфике проекта: IT-сфере, строительстве, архитектуре или других областях.
• Умение работать с людьми. Способность сформировать и отладить работу внутри команды – половина успеха проекта.
• Личностные качества: ответственность, коммуникабельность, аналитический склад ума, стрессоустойчивость, многозадачность и оптимизм.

Преимущества проектного метода управления и его недостатки

Плюсы проектного управления:

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

Минусы формата:

• Недостаток ресурсов. Часто у маленьких компаний не хватает средств на перераспределение бюджетов и других ресурсов между несколькими проектами.
• Высокие требования к квалификации руководителя. На рынке недостаточно проект-менеджеров с нужными навыками и опытом.
• Сложности перехода. Изменить традиционную систему управления на проектную сложно и занимает много времени.

Основные этапы управления проектом

Управление проектом – это комплекс действий. Количество и сложность задач, их последовательность зависят от вида проекта: например, строительство дома сильно отличается от работы над разработкой мобильного приложения. Но все проекты, вне зависимости от специфики, проходят примерно одинаковые этапы развития. Их называют жизненным циклом. Рассмотрим основные этапы управления проектом.

Инициирование проекта

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

Планирование проекта

Теперь нужно определить, как именно будет выполняться проект:

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

Планирование – это не только создание плана на старте, но и способность подготовиться к будущим проблемам, правкам и изменениям требований.

Исполнение проекта

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

Мониторинг и контроль проекта

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

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

Закрытие проекта

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

Подходы к управлению жизненным циклом проекта

Жизненным циклом можно управлять: от этого зависит результативность проекта. По подходам к управлению жизненные циклы делят на:

1. Предиктивные. Для него характерны четкое планирование задач, бюджетов и сроков на самом раннем этапе. В такой алгоритм трудно внести изменения, потому что тогда придется менять всю взаимосвязанную систему планирования. Подходит для проектов с четким пониманием продукта.
2. Итеративно-инкрементные. Итеративность заключаются в том, что команда повторяет операции проекта столько раз, сколько требуется для достижения результата. А инкрементность заключается в постепенном наращивании функционала операций, пока не будут удовлетворены требования заказчика.
3. Гибкий. Этот подход применяется в областях, где нужно быстро реагировать на изменения требований. Он включает элементы итеративности и инкрементности.

Какую выбрать методологию

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

Waterfall

Эту модель еще называют каскадной или водопадной. Главный принцип метода – последовательное и четкое соблюдение всех этапов по заранее продуманному плану. Например, этапы разработки IT-продукта по методологии Waterfall:

• аналитика;
• проектирование;
• разработка;
• тестирование;
• эксплуатация и поддержка.

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

Agile

В отличие от Waterfall, Agile – целый набор гибких методик. Его главная ценность – это качество продукта, поэтому agile-команды постоянно поддерживают контакт с заказчиком и готовы к любым изменениям и доработкам. Обычно методология используется в IT-сфере при работе небольших групп сотрудников, занятых творческой работой.

Scrum

Scrum – это часть методологии Agile. Здесь тоже в приоритете результат и удовлетворение запросов заказчика, поэтому его максимально вовлекают в процесс. Работа состоит из коротких периодов – спринтов. В рамках спринта создается часть продукта, которую тестируют демонстрируют клиенту. По обратной связи от клиента команда улучшает эффективность.

Kanban

«Kanban» переводится как «доска объявлений». Это тоже часть Agile-философии, включающая ее базовые принципы. Методологию используют для равномерного распределения обязанностей между сотрудниками, чтобы не перегрузить команду.

Система построена на визуализации задач: можно отмечать задачи на обычной доске или использовать онлайн-сервисы, например, Trello. Весь процесс делится на этапы. На доске это выглядит как столбцы: «сделано», «в работе» и «готово», куда добавляют задачи. Любой член команды может следить за ходом дел, найти ответственного за конкретную задачу, и скорректировать ход работы.

Инструменты для управления проектами

Чтобы руководителю было проще выстраивать и контролировать процессы, разработчики создают специальные сервисы и ПО, которые автоматизируют часть работы. Самые популярные:

• Битрикс24 – российский сервис для управления бизнесом: поддерживает работу с Kanban, диаграммой Ганта, обеспечивает продвинутую фильтрацию в задачах.
• Jira – это система отслеживания ошибок в программном коде. При этом множество компаний использует ее инструментарий для управления проектами. Подходит для работы по Scrum и Kanban.
• Asana – это приложение для управления командными проектами. Есть система удобных тегов, можно анализировать эффективность и управлять несколькими проектами в рамках одной команды.

Заключение

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

08 Июл 2016

Источник: https://zapier.com/learn/ultimate-guide-to-project-management/project-management-systems/

«Из всех трудностей, с которыми столкнулись НАСА, отправляя человека на Луну, управление было наверно самой сложной задачей»

— Роджер Лаунис, историк НАСА

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

И хотя лишь единицы из нас столкнутся с задачами такого масштаба, большинство читателей этого блога так или иначе сталкивается с проектным управлением. По оценкам PMI к 2020 году появятся 15 миллионов новых позиций проектных специалистов – а многим другим профессионалам зачастую приходится руководить мини-проектами, хотя бы на личном уровне.

Говоря простыми словами, Управление проектами – это управление и организация всего, что нужно для достижения цели – вовремя и в рамках бюджета, конечно же. Будь до разработка нового программного обеспечения, проведение маркетинговой компании или высадка человека на Марс – проектное управление позволяет добиться успеха.

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

Разработанные подходы сильно отличаются друг от друга. Они различаются по областям применения, детализированности, самодостаточности и формализации. В заголовке мы назвали их «методами» для удобства, но на самом деле в статье представлены стандарты, концепции, методы и фреймворки, которые применяются в управлении проектами. Цель данной статьи — дать наиболее широкий обзор существующих в управлении проектами подходов.

В этой статье мы рассмотрим:

• Классический проектный менеджмент
• Agile
• Scrum
• Lean
• Kanban
• Six Sigma
• PRINCE2

И прежде чем рассматривать конкретные методы, давайте ответим на очевидный вопрос – «А зачем вообще нужны системы и методы управления проектами?» – рассмотрим, естественно, кратко, историю управления проектами и определим базовые термины проектного управления.

Почему «управление проектами»?

Имена Нила Армстронга и Базза Олдрина навсегда войдут в историю как символы одного из величайших достижений человечества – высадке человека на Луну. Однако основной вклад в это событие внесли 400 000 сотрудников НАСА и 20 000 компаний и университетов, работавших вместе над миссией «Аполлон».

В 1961 году Джон Кеннеди поставил задачу высадить человека на спутнике Земли и вернуть его обратно – при том, что на тот момент НАСА отправляли человека в космос лишь на 15 минут. Такая амбициозная цель потребовала невероятного количества ресурсов, кооперации, инноваций и планирования.

Как говорится в книге НАСА «Managing the Moon Program», основная проблема состояла не в том, «что делать?», а в том, «как сделать столько за такой короткий срок?». По словам доктора Макса Фагета (Dr. Max Faget), главы инжиниринга в Космическом центра имени Линдона Джонсона (The Lyndon B. Johnson Space Center, JSC), тогда в НАСА не представляли, как уложить все необходимые действия в 10 лет. А потому первым шагом стало «разбить проект на управляемые этапы».

Затем важно было ускорить выполнение каждой отдельной фазы и удостовериться, что команды и компании, работающие на каждой фазе, эффективно взаимодействуют друг с другом и вовремя поставляют результаты. Эта задача была возложена на доктора Джорджа Мюллера (George E. Muller), управлявшего каждой частью проекта «Аполлон», от Белого Дома до поставщика самой мелкой детали. Чтобы контролировать проект было легче, он решил разбить проект на 5 областей: «Контроль Программы», «Системная Инженерия», «Тестирование», «Надёжность и Качество» и «Лётная эксплуатация». Схема управления программой Аполлон представлена на Рисунке 1.

Эта система из 5 этапов – названных «Этапами GEM» в честь инициалов доктора Мюллера – была разработаны «ради фокусировки на тестировании продукта, и на его разработке с учётом того, что его будут тестировать», как отмечает сам Мюллер. «Контроль Программы» определял, что нужно сделать, управлял бюджетом и требованиями, а также управлял взаимосвязями элементов программы. Область «Системная инженерия» отвечала за разработку новых устройств и узлов, «Тестирование» за то, что эти новые элементы работают, «Надёжность и Качество» проверяли разработанные элементы на соответствие требованиям и стандартам, а «Лётная эксплуатация» отвечала за то, что эти узлы будут работать во время полёта.

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

Краткая история проектного управления

Проектное управление не было изобретено НАСА и доктором Мюллером. Египетские пирамиды и Великая Китайская стена являются продуктами проектного управления из доисторических эпох. К сожалению, документальных свидетельств того, как проходила реализация и управления этими проектами не сохранилось, и нынешнее проектное управление оторвано от знаний прошлых веков.

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

Однако, если Вы – шеф-повар, и готовите не одно блюдо, а несколько, например, салат (приготовление которого состоит из 3 этапов) и десерт (который нужно только подать), то Вам потребуется инструмент, позволяющий отслеживать временные затраты на каждый из элементов и время, когда они должны быть готовы. И тут на помощь приходит один из первых современных инструментов проектного управления: Диаграмма Гантта, представленная на Рисунке 2.

Изобретённая независимо Королем Адамеки (Korol Adamecki) и Генри Л. Ганттом (Genry L. Gantt) в начале XX в., диаграмма Гантта показывает расписание проекта основываясь на датах окончания и завершения задач. В неё вносятся задачи, их длительности и взаимосвязи, а затем высчитывается критический путь – самая длинная цепочка взаимосвязанных задач, определяющих длительность проекта. Взаимосвязи между началом и окончанием разных задач очень важны – вы же не можете подать гостям суп, пока вы его не сварили, не так ли?

Так вот, типовой проект очень похож на проект приготовления и подачи ужина, только в нём гораздо больше задач, взаимосвязей, дедлайнов и видов ресурсов. Проектам с жёсткими дедлайнами диаграмма Гантта помогает решить, когда лучше начинать те или иные задачи, чтобы сократить время реализации. А для проектов с сильными ресурсными ограничениями, диаграмма Гантта предоставляет возможность построить схему в форме событийной цепочки процессов (event-driven process chain) для планирования ресурсов.

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

Для таких проектов лучше подходят гибкие методы управления проектами Agile и связанные с ним подходы, такие как Lean, Kanban и другие. Есть и методы, позволяющие управлять как рабочим потоком, так и временем, и ресурсами – 6 Сигм и Scrum.

Популярные системы управления проектами

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

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

Базовые термины проектного управления

Agile: Гибкий итеративно-инкрементальный подход к управлению проектами и продуктами, ориентированный на динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует множество методов, базирующихся на идеях Agile, самые популярные из которых – Scrum и Kanban.

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

Событийная цепочка процессов (EPC-диаграмма): диаграмма, отображающая последовательность реализации работ проектов основываясь на доступности и загруженности ресурсов

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

Веха (контрольная точка, milestone): Ключевое событие, обозначающее, например, конец этапа. На диаграмме Гантта обозначается задачей с нулевой длительностью.

Менеджер проекта (руководитель проекта, project manager, PM): Руководитель команды проекта, ответственный за управление проектом (планирование, реализацию и закрытие проекта).

Ресурсы: Элементы, необходимые для реализации проекта. Ресурсами являются время, оборудование, материалы, сотрудники и прочее.

Содержание проекта (Scope): Описание работ, которые необходимо выполнить, чтобы получить продукт.

Спринт (Sprint): Итерация (рабочий цикл) в Scrum, длящаяся от недели до месяца, в ходе которой создаётся рабочая версия продукта или его элемент, представляющий ценность для заказчика.

«Классическое» или «традиционное» проектное управление: Наиболее широко распространённый метод управления проектами, основанный на так называемом «водопадном» (Waterfall) или каскадном цикле, при котором задача передаётся последовательно по этапам, напоминающим поток.

Далее мы рассмотрим различные подходы к управлению проектами более подробно. Мы начнём с Классического проектного управления и Agile, а затем рассмотрим Scrum, Kanban, 6 сигм и другие.

Классическое проектное управление

Наиболее очевидный способ сделать свой проект более управляемым – это разбить процесс его исполнения на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. В этом смысле оно напоминает компьютерную игру – нельзя перейти на следующий уровень не завершив предыдущий. Схема рабочего процесса приведена на Рисунке 3.

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

Обычно выделяют 5 этапов классического проектного управления, но можно добавлять и дополнительные этапы, если того требует проект.

5 этапов традиционного менеджмента:

Этап 1. Инициация. Руководитель проекта и команда определяют требования к проекту. На данном этапе часто проводятся совещания и «мозговые штурмы», на которых определяется что же должен представлять из себя продукт проекта.

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

Этап 3. Разработка. Данная стадия реализуется не для всех проектов — как правило она является частью фазы планирования. В фазе разработки, характерной для технологических проектов, определяется конфигурация будущего проекта и/или продукта и технические способы его достижения. Например в ИТ-проектах на данном этапе выбирается язык программирования. (В отечественной практике данная фаза обычно не выделяется, а термин «разработка» не используется — прим. пер.)

Этап 4. Реализация и тестирование. На этой фазе происходит собственно основная работа по проекту – написание кода, возведение здания и тому подобное. Следуя разработанным планам начинает создаваться содержание проекта, определённое ранее, проводится контроль по выбранным метрикам. Во второй части данной фазы происходит тестирование продукта, он проверяется на соответствие требованиям Заказчика и заинтересованных сторон. В части тестирования выявляются и исправляются недостатки продукта.

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

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

Благодаря тому, что классический проектный менеджмент строго привязан ко времени исполнения задач, как правило, заранее определённому на этапе планирования, для реализации проектов в рамках данного подхода отлично подходят инструменты календарно-сетевого планирования. Самым распространённым инструментом календарно-сетевого планирования является уже упомянутая ранее диаграмма Гантта. Существует множество инструментов для её построения – от простых таблиц вроде Excel и Smartsheet до профессиональных программных пакетов вроде Microsoft Project и Primavera.

Сильные стороны классического проектного менеджмента

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

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

Слабые стороны классического проектного менеджмента

Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Руководство компании Toyota, знаменитую созданием таких систем как Lean и Kanban, часто критикуют за то, что они применяют классический подход в разработке софта для своей компании, причём именно за недостаток гибкости.

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

Agile

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

И тут в игру вступает Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Схема работы приведена на Рисунке 5.

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

Несмотря на то, что Agile вошёл в моду относительно недавно, идея итеративной разработки не нова (об истории появления Agile можно прочесть здесь – прим.пер.). Своё нынешнее название семейство гибких методологий получило в 2001 с публикации Манифеста Agile (Agile Manifesto), закрепившем основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, даже «любовь» к изменениям.

Сам по себе Agile – не метод управления проектами. Это скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют, фреймворки (frameworks): Scrum, Kanban, Crystal, и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам.

Сильные стороны Agile

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

Один из принципов Agile: «Реакция на изменения важнее следования плану». Именно быстрая и относительно безболезненная реакция на изменения является причиной тому, что многие крупные компании стремятся сделать свои процессы более гибкими. Кроме того, Agile отлично подходит для проектов с «открытым концом» — например, запуску сервиса или блога.

Вотчина  Agile – разработка новых, инновационных продуктов. В проектах по разработке таких продуктов высока доля неопределённости, а информация о продукте раскрывается по ходу проекта. В таких условиях реализовывать проект по «водопаду» становится невозможно– нет информации для планирования.

Слабые стороны Agile

В отличие от PRINCE2 и PMBOK Agile – не является ни методологией, ни стандартом. Agile — это набор принципов и ценностей. Слабая сторона состоит в том, что каждой команде придётся самостоятельно составлять свою систему управления, руководствуясь принципами Agile. Это непростой и длительный процесс, который потребует изменений всей организации, начиная процедурами и заканчивая базовыми ценностями. Это тернистый путь и не всем организациям он под силу.

Этот путь потребует от лидера изменений не только знаний и упорства, но и серьёзных административных ресурсов, а также затрат. К счастью, существуют готовые наборы практик, которые облегчают Agile-трансформацию организации. К таким наборам относятся фреймворк Scrum, метод Kanban и многие другие – Crystal, LeSS, SAFe, Nexus.

Scrum

Гибкий фреймворк, созданный в 1986 году, считается самым структурированным из семейства Agile. Созданный в 1986 году, он сочетает в себе элементы классического процесса и идеи гибкого подхода к управлению проектами. В итоге получилось очень сбалансированное сочетание гибкости и структурированности.

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов (product backlog). И несмотря на то, что «задел продукта» — достаточно верный перевод и используется в профессиональной литературе, в российской практике чаще всего используется просто «беклог». Затем эти части приоретизируются Владельцем продукта – представителем Заказчика в команде. Самые важные «кусочки» первыми отбираются для выполнения в Спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель.  В конце Спринта Заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему Спринту. Длительность у Спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям Заказчика, которые имеют свойство изменяться со временем, перед началом каждого Спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, Scrum Мастер (Scrum Master, лидер команды проекта) и Владелец продукта. И ответственность за этот процесс лежит на всех.

Как уже говорилось, Владелец продукта является представителем Заказчика в проекте, или олицетворяет всех клиентов будущего проекта, в случае если Заказчика нет. Для этого он должен досконально знать их потребности и образ мышления, а также разбираться в продукте и технологии его изготовления. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача — следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены.

Основная структура процессов Scrum вращается вокруг 5 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

• Встреча по упорядочиванию беклога (Backlog Refinement Meeting, «Backlog Grooming»): Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него него зависит, какую ценность получит Заказчик по итогам спринта.
• Планирование Спринта: После того, как Владелец продукта определил приоритеты, команда совместно решает, что же конкретно они будут делать во время грядущей итерации, как достигнуть поставленной на предыдущей встрече цели. Команды могут применять различные инструменты планирования и оценки на данном этапе, лишь бы они не противоречили принципам и логике Scrum. Планирование Спринта проводится в самом начале итерации, после Встречи по упорядочиванию продукта.
• Ежедневные летучки: Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.
• Подведение итогов Спринта: Цель этапа – обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача – убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта.
• Ретроспектива Спринта: Проводится сразу после Подведения итогов спринта и до планирования следующего спринта. На нём команда выясняет, насколько чётко и слаженно проходил процесс реализации этапа. Обследованию подвергаются возникшие проблемы в работе, методологии и взаимодействии. Именно этот этап позволяет команде провести рефлексию и следующий Спринт провести эффективнее.

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

Сильные стороны Scrum

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

Онлайн телеканал Netflix является отличным примером быстрых поставок результатов. Сайт ресурса обновляется каждые две недели благодаря Scrum, который не просто позволяет работать с высокой скорости, но и аккумулирует пользовательский опыт и даёт возможность выявить самое главное для клиентов.

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

Слабые стороны Scrum

Scrum очень требователен к команде проекта. Она должна быть небольшой (5-9 человек) и кроссфункциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Например разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике. Делается это для того, чтобы часть команды не «простаивала» на разных этапах проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга.

Кроме того, члены команды должны быть «командными игроками», активно брать на себя ответственность и уметь самоорганизовываться. Подобрать такую зрелую  команду очень непросто!

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

 Lean

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

В Lean, так же, как и в Scrum, работа разбивается на небольшие пакеты поставки, которые реализуются отдельно и независимо. Но в Lean для разработки каждого пакета поставки существует поток операций с этапами, подобными тем, которые были созданы для проекта Аполлон. Как и в классическом проектном менеджменте, это могут быть этапы планирования, разработки, производства, тестирования и поставки – или любые другие необходимые для качественной реализации проектов этапы.

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

Как и Agile, Lean это скорее концепция, образ мышления, нежели нечто высеченное в камне. Используя идеи Lean Вы можете самостоятельно создать систему, удовлетворяющую вашим требованиям в управлении проектами.

Сильные стороны Lean

Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны Lean

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

А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и чётких коммуникаций  ̶  главное помнить об этом.

Kanban

Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Созданный инженером компании Toyota Тайичи Оно (Taiichi Ono) в 1953 году, Kanban очень похож на схему промышленного производства. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент.

Кроме того, создатель Kanban вдохновлялся супермаркетами, а именно их принципом – «держи на полках только то, что нужно клиенту». А потому в Kanban разрешается оставить неоконченную задачу на одном из этапов, если её приоритет изменился и есть другие срочные задачи. Неотредактированная статья для блога, подвешенная без даты публикации или часть кода функции, которую возможно не будут включать в продукт – всё это нормально для работы по Kanban.

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

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

Ваша собственная система Kanban может быть настолько гибкой, насколько Вы сами того пожелаете – ведь во многом Kanban является визуализацией идеи Agile. Но у Kanban есть 4 столпа, на которых держится вся система:

1. Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.
2. Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
3. Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
4. Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

Сильные стороны Kanban

Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.

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

Слабые стороны Kanban

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

6 сигм (Six Sigma)

Компания Motorola, наряду с Toyota, также внесла вклад в развитие мирового проектного управления. Инженер этой компании Bill Smith создал концепцию 6 сигм в 1986 году. Это более структурированная версия Lean нежели Kanban, в которую добавлено больше планирования для экономии ресурсов, повышения качества, также снижения количества брака и проблем.

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

Для этого было предложен процесс из 5 шагов, известных как DMEDI:

• Определение (Define): Первый этап очень похож на ранние этапы других систем проектного управления. На нём определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели.
• Измерение (Measure): 6 сигм ориентирована на сбор и анализ количественных данных о проекте. На данном этапе происходят определяется, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать.
• Исследование (Explore): На стадии исследования менеджер проекта решает, каким же образом команда может достичь поставленных целей и исполнить все требования в срок и в рамках бюджета. На данном этапе очень важно нестандартное мышление руководителя проектов при решении возникших проблем.
• Разработка (Develop): На данном этапе реализуются планы и решения, принятые на предыдущих этапах. Важно понимать, что на данном этапе необходим детальный план, в котором описаны все действия, необходимые для достижения поставленных целей. Также на данном этапе измеряется прогресс проекта.
• Контроль (Control): Ключевой этап в методологии 6 сигм. Его основная задача – долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования извлечённых уроков, анализа собранных данных и применения полученных знаний как в проектах, так во всей компании в целом.

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

Сильные стороны 6 сигм

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

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

Слабые стороны 6 сигм

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

Кроме того, основной лейтмотив 6 сигм: «Всё всегда можно сделать ещё лучше». Это может демотивировать сотрудников, не чувствующих удовлетворения от проделанной работы. Кроме того, если проект единичный и компания не планирует в будущем реализовывать подобные проекты, все затраты на анализ и извлечение уроков могут оказаться напрасными.

PRINCE2

НАСА – не единственная государственная организация, которая внесла вклад в развитие проектного управления. Британское Правительство давно оценило эффективность проектного управления, и в 1989 году была создана британская методология PRINCE2. Название произошло от акронима «PRojects IN Controlled Environments version 2», что переводится как «Проекты в контролируемой среде версия 2». В отличие от гибких методов, PRINCE2 не использует итеративный подход к проекту. Если сравнивать PRINCE2 другими продуктами, то его можно сравнить с гибридом классического подхода к проектному управлению и концентрации на качестве из 6 сигм.

Методология PRINCE2 в отличие от, например, свода знаний PMBOK не содержит:

• Специализированных аспектов управления проектом, например, отраслевых;
• Конкретных практик и инструментов управления проектами, таких как диаграмма Гантта, WBS и т.п.

PRINCE2 концентрируется на управленческих сторонах проекта, выраженных в 7 принципах, 7 процессах и 7 темах проекта.

• 7 принципов определяют общие правила управления проектами по PRINCE2, определяют базу методологии;
• 7 процессов определяют шаги продвижения по проектному циклу;
• 7 тем – аспекты, по которым проводится контроль для достижения успеха проекта.

Кроме того, PRINCE2 рекомендует адаптировать методологию под каждую конкретную организацию.

В начале проекта PRINCE2 предлагает нам определить 3 основных аспекта проекта:

• Бизнес-аспект (Принесёт ли этот проект выгоду?)
• Потребительский аспект (Какой нужен продукт, что мы будем делать?)
• Ресурсный аспект (Достаточно ли у нас всего, чтобы достичь цели?)

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

Согласно PRINCE2 у каждого члена команды есть своя чёткая роль в каждом из 7 процессов:

• Начало проекта (Starting up a project):В ходе данного процесса назначается менеджер проекта и определяются общие требования к характеристикам продукта. Менеджер проекта, чья основная задача – внимание к деталям, отчитывается перед Управляющим комитетом проекта, который отвечает за общее руководство проектом. Именно Управляющий комитет следит за тем, чтобы проект не сбился с курса, и он же полностью отвечает за успех проекта.
• Инициация проекта (Initiation a project):В ходе данного процесса менеджер проекта составляет «Документацию по инициации проекта», в которой содержится план проекта по стадиям. Стадии могут длиться разное количество времени, но, как и в классическом подходе, они следуют строго друг за другом.
• Руководство проектом (Directing a project): Данный процесс предоставляет возможность Управляющему комитету нести общую ответственность за успех проекта, не погружаясь в детали, которые находятся в границах полномочий менеджера проекта.
• Контроль стадии (Controlling a stage):При реализации проекта, даже в идеальных условиях, будут вноситься определённые изменения. Процесс «Контроль стадии» реализует один из принципов PRINCE2 – принцип управления по исключениям. В обязанности менеджера проекта входит отслеживать в ходе выполнения стадии отклонения от плановых параметров проекта по срокам, содержанию, бюджету и др. Если эти отклонения превышают данные руководителю проекта Управляющим комитетом полномочия (в терминологии PRINCE2 – допуски), менеджер проекта обязан проинформировать Управляющий комитет и предложить пути выхода из ситуации.
• Управление созданием продукта (Managing Product Delivery):Процесс управления созданием продукта представляет собой взаимодействие менеджера проекта и менеджера команды по созданию одного из продуктов проекта. В обязанности менеджера проекта в данном процессе входит делегирование полномочий по созданию продукта менеджеру команды и приемка созданного продукта.
• Управление границами стадии (Managing a stage boundary): В ходе данного процесса менеджер проекта предоставляет Управляющему комитету всю необходимую информацию для оценки результатов пройденной стадии и принятия решения о переходе на следующую стадию.
• Завершение проекта (Closing a project):Одно из отличий PRINCE2 в том, что процесс завершения проекта не выделяется в отдельный этап или стадию, как в классическом подходе, а выполняется в рамках финальной стадии создания продукта. Цель процесса – подтвердить, что продукт проекта принят, или проект больше не может принести ничего полезного.

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

Сильные стороны PRINCE2

• Адаптируемость к особенностям организации;
• Наличие чёткого описания ролей и распределения ответственности;
• Акцент на продуктах проекта;
• Определённые уровни управления;
• Фокус на экономической целесообразности;
• Последовательность проектной работы;
• Акцент на фиксации опыта и постоянном совершенствовании.

Слабые стороны PRINCE2

• Отсутствие отраслевых практик;
• Отсутствие конкретных инструментов для работы в проекте.

Лучшая система управления проектами … для Вас!

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

Как получить международный сертификат по Agile?

Для тех, кто хочет получить систематизированное понимание Agile, разобраться с преимуществами и недостатками гибкого подхода к проектам и продуктам, найти области наилучшего применения Agile и получить международный сертификат ICAgile Certified Professional — наш тренинг «Agile Certified Professional»

Наши курсы и тренинги:

• Курс «Управление проектами на базе PRINCE2»
• Тренинг «Agile Certified Professional»
• Базовый курс управления проектами

Самые популярные статьи:

• Статья: Партизанский Аджайл
• Статья: ТОП-4 Методологии управления проектами
• Статья: Разница между Scrum и Kanban

Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи: 

• Telegram-канал «Product Lab и Проектные сервисы»
• Telegram-канал Андрея Бадина, CEO «Проектных сервисов», — «Управляй иначе»
• YouTube
• VK