Как делать проекты, не стреляя себе в ногу

Советы по управлению проектами от бывшего руководителя отдела разработки агентства Friends Moscow Петра Фомичёва.

Про управление людьми очень хорошо сказал Егор Волков из компании Greensight: «Люди всегда всё портят. Они обещают и не делают. Или делают, но не так. Или так, но не то. Или то, но долго. Было бы здорово как-нибудь так построить бизнес, чтобы без людей».

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

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

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

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

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

Я обещаю, что не будет сложных инструментов — всё будет просто.

Энтропия? Я что, читаю vc.ru ради умных слов?

Энтропия — это то, что разрушает все наши замыслы. Чтобы попасть на тренировку к 10:00, мне надо встать хотя бы в 8:30. Я уверенно ложусь спать в 1 час ночи — без тени сомнений, что завтра в 10 тренер будет ругаться за то, что я опять пил на выходных и поэтому бью троечку слишком медленно. Всё спланировано, и Google Home готов разбудить меня вовремя. Угадайте, кто незаметно для себя во сне отключает будильник?

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

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

Человечество только этим и занимается: мы научились выращивать пшеницу, чтобы не зависеть от плодов в лесах, потом одомашнили коров, ибо не набегаешься за ними по всей округе. Приручили собак, чтобы они управляли стадом. И так далее, вплоть до стабильной работы с 9 до 17 с часовым перерывом на веганский обед.

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

Тут мы приходим к двум важным пунктам:

  1. Любой проект преследует цель. Это может быть отпуск, запуск сайта, продукта или просто печать плакатов. Проект нужен, чтобы достичь цели.
  2. Достижению цели будет мешать примерно всё. Бюджетные, временные, технические ограничения, а также внутренние, которые создают люди, неизменно участвующие в процессе.

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

Учимся рисовать

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

Если у вас нет шанса спастись и пойти кормить соек с лучшей девушкой в этом городе — с этой секунды для вас начинается проект.

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

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

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

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

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

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

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

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

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

Делаем крутое ТЗ

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

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

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

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

Загадка: сколько реализовывался проект, на который было отведено 3 месяца?

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

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

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

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

Бесконечная презентация о том, как должен работать проект.

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

Кусочек ТЗ для проекта с видеотрансляцией. Дальше его используют в качестве приложения к договору

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

Погоди. А где разработчики?

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

Я поклонник двух мыслей:

  1. Менеджер проекта, если он руководит разработкой, должен уметь кодить. Он не должен уметь писать продакшн-код, но он должен находиться на уровне, когда сам может залезть в документацию к API, посмотреть методы и что-то уточнить. Менеджер должен не только понимать, как строится разработка и что значит писать код, но и осознавать, как мыслят программисты: это значительно улучшит коммуникацию с ними. Я полностью понимаю компании, когда они нанимают менеджеров проектов с техническим образованием. И не очень понимаю те организации, которые сажают в кресла проект-менеджера кого ни попадя.
  2. Разработчиков нужно привлекать к обсуждению и планированию проекта как можно раньше. Не стоит думать, что разработчики дураки и ничего не понимают в бизнес-задачах — чем раньше они начнут помогать продумывать техническую сторону вопроса, тем больше времени будет сэкономлено на следующих шагах. Круто, если вы можете приглашать хотя бы одного программиста на сессии проектирования и советоваться с ним в процессе написания документации. Имея такую возможность, пользуйтесь ей постоянно. К сожалению, во многих компаниях это невозможно, поэтому смотри пункт первый — вы должны сами разбираться в технической области ровно настолько, сколько требуется для принятия взвешенных решений о функциональности.

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

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

Небольшой подытог этих страниц:

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

Ахиллесова пята всех проектов

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

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

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

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

Что нам надо сделать:

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

Декомпозиция выглядит так:

Это метод «от общего к частному», где схема строится от глобальных элементов к самым маленьким. PMBoK описывает несколько случаев декомпозиции: по процессам и по элементам. Честно говоря, мне ни разу не приходилось расписывать процессы с помощью декомпозиции, а вот функциональность — постоянно.

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

Декомпозиция какого-то старого проекта. Здесь от глобального элемента Landing page исходят следующие области: “Elements”, перечисляющая все элементы на страницы, “Content”, перечисляющая все элементы контента, и “Mechanics”, включающая в себя особые элементы логики. Я делаю декомпозицию в XMind, но это олдскул, и есть облачные решения.

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

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

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

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

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

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

Я использую связку Instagantt и Asana, потому что Asana является нашим штатным таск-трекером, а Instagantt подключается к нему. В моём случае нет смысла контролировать такие метрики, как расход часов и загрузку ресурсов, так что нас всё устраивает. Решений для таймингов и таск-трекеров — вагон и маленькая тележка, выбирайте то, которое подходит вам.

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

Упс, похоже, что-то идёт не так — таски горят красным! Да и ещё ни один не зафиксирован за исполнителем — совсем беда

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

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

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

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

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

Очень много do nothing — похоже, мы изрядно ленивы

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

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

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

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

На этом этапе у нас есть все составляющие хорошего плана:

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

Мы, наконец, доделали нашу панель управления. Но как мы будем использовать всё это? Может ли менеджер после планирования уезжать в отпуск — ведь график загруженности тонко намекает на это? Разорвут ли обстоятельства наш проект?

Обо всём этом — во второй части, которую я напишу через неделю.

И если вдруг у вас есть желание предложить мне работу, то можно писать в Facebook или на почту: [email protected].

0
43 комментария
Написать комментарий...
Иван Крамарчук

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

Ответить
Развернуть ветку
Олег Нечаев

Спасибо. Интересно. Но вот про энтропию с девушкой было самое интересное. Но в данном примере вы и заказчик и исполнитель. Вывод:
1. Иметь четкий план отдохнуть с девушкой в обозначенный срок.
2. Минимизировать риски - найти запасных девушек. Риск-карта.
3. Оценить худший вариант - ни одна не полетела.
4. Иметь план Б. Сдать билет, получить деньги.
5. По прилёту использовать сэкономленные в предыдущем пункте ресурсы на местную девушку или девушек. Тайминг. Не затягивать с этим. С UX можно разобраться потом, главное чтобы она быстро ответила да. Поклонники Agile пусть собирают ромашки и выбирают конфеты.
6. Постоянно сверяться с техническим специалистом, можно ли реализовать все желания, если вы не в Голландии.

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

Ответить
Развернуть ветку
Stan Podolski

девушка - waterfall или девушка - agile. Вот вопрос вопросов

Ответить
Развернуть ветку
Олег Нечаев

Если waterfall растянуто во времени, особенно фаза поддержки, то определённо жена получится. А у нас дедлайн и билеты обратно. agile и другие гибкие методологии - "У неё наверное кто-то есть. Красную рубаху надеть или белую? Одену майку. Посмотрим как пойдет. Поцеловать или сначала цветы? Сначала цветы...и выпить" могут затянуть процесс. Технология быстрого результата (ТБР) от 1С тут более применима)))

Ответить
Развернуть ветку
Stan Podolski

Вы точно знаете, что означает слово энтропия?

Ответить
Развернуть ветку
Sasha Kudla

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

Ответить
Развернуть ветку
Mihail

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

В основном же впихивают не те знания и не так да ещё и винтик из человека делают.

Ответить
Развернуть ветку
Sasha Kudla

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

Ответить
Развернуть ветку
Stan Podolski

Лично я считаю, что делать винтик бесполезно - нужно делать или шурупчик или саморез

Вот тут я предлагаю открыть дебаты!

Ответить
Развернуть ветку
Mihail

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

Ответить
Развернуть ветку
Stan Podolski

да... Это конечно вопрос!

И все же я за правильную ориентацию, за правую. Кто там шагает левой? Правой, правой, правой!

Ответить
Развернуть ветку
Peter Fomichev
Автор

Замечу, что почти все это указывается в стандарте PMBoK - ему лет почти столько же, сколько мне :) Дело, наверное, не в том что теории устарели - а как их подают.

Но, рад если мои мысли показались вам полезными.

Ответить
Развернуть ветку
Stan Podolski

вы даже не представляете, сколько лет евклидовой геометрии. А пифагоровы штаны все еще преподают в школах...

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Stan Podolski

а энтропия?

Ответить
Развернуть ветку
Вячеслав Осадчий

Очень интересно, спасибо. Я сам разработчик, и сейчас пробую себя на позиции PM, поэтому такая статья очень полезна.

Ответить
Развернуть ветку
Mark Rapida Gromov
беру фотографии мокапов из сессии проектирования и с помощью Sketch перевожу их в картинки

што?

Ответить
Развернуть ветку
Mark Rapida Gromov

простите, затупил спросонья
минусов отгрузите, пожалуйста

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

- это нужно на первую полосу
Хорошая статья! Ждём продолжения

Ответить
Развернуть ветку
Дмитрий Щербаков

Очень круто, описано доступным языком, спасибо.

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

Говорю по своему опыту, когда в начале работы клиенту рассказываешь как делать все правильно: проектирование, ТЗ, тесты потом озвучиваешь что стоимость разработки увеличится раза в 2-3 клиент сразу прыгает в кусты ))

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

Ответить
Развернуть ветку
Павел Скиннер

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

Ответить
Развернуть ветку
Дмитрий Щербаков

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

Ответить
Развернуть ветку
Вася Бездомный

Менеджер проекта руководящий разработкой? Это возможно только в небольших проектах. Да и тут непонятно зачем менеджеру проекта подменять тим-лида или тим-лиду брать на себя обязанности менеджера.

Ответить
Развернуть ветку
Mark Rapida Gromov

есть такое понятие, как «менеджер продукта». И это уже точно не для «небольших» проектов

Ответить
Развернуть ветку
Вася Бездомный

Менеджер продукта тем более не должен лезть в разработку, например в СКРАМ это вообще запрещено для владельца продукта. Хотя, конечно скрамом продуктовая разработка не ограничивается...

Ответить
Развернуть ветку
Pavel Ivanov

Давай начнём с того, что в России малый процент компаний понимает разницу между продакт- и проджект-менеджером, между тимлидом и техлидом, между старшим и ведущим разработчиком, между CIO и CTO. И так далее. Дай бог, в среднестатистическом IT приходится всего 2 роли совмещать. Обычно - больше.

Ответить
Развернуть ветку
Mark Rapida Gromov

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

Ответить
Развернуть ветку
Алексей Струков

"После того как мы назначили степени для каждого риска, команда должна выработать планы А и Б (можно В и Д, лишним не бывает) для нивелирования этого риска."

Один сановник трижды думал прежде, чем что-то сделать. Услышав об этом, Конфуций сказал:
- Достаточно и двух раз.

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

А что дает степень урона? Возможность отсортировать риски по значимости?)

Ответить
Развернуть ветку
Peter Fomichev
Автор

Привет.

1. Ну да :)
2. Степень урона нужна для понимания, что более важно, что менее важно. Предположим, что у нас есть всего три риска:

- Риск того, что дизайнер не успеет сдать в срок и мы не сможем вовремя начать фронт. Назначим ему значение урона 400 из 1000, а вероятность 3 из 5 (не лучший у нас дизайнер, раздолбай)
- Риск того, что внешняя платформа поменяет какие-нибудь методы API и что-то нам запретит из нужного. Вероятность 1 из 5, а урон 900 из 1000, проект вообще не случится без этого.
- И еще один риск того, что нам не поставят вовремя контент для шеров. Урон не страшный - всего 100 из 1000, а вероятность пусть будет 4 из 5.

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

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

Ответить
Развернуть ветку
Алексей Струков

Привет. Ясно. А не пробовали придумать/позаимствовать методологию преобразования рисков в дополнительные затраты (финансовые или временные)?

Ответить
Развернуть ветку
Peter Fomichev
Автор

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

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

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

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

Ответить
Развернуть ветку
Алексей Струков

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

Ответить
Развернуть ветку
Peter Fomichev
Автор

Ну так и есть, web основной, но есть чуть-чуть мобилок тоже, хотя это не очень актуально для нас.

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

Ответить
Развернуть ветку
Александр Батищев

Отлично написано, жду продолжения

Ответить
Развернуть ветку
Pol Bal

Материал отличный. Спасибо

Ответить
Развернуть ветку
Александр Свечкарёв

"Я лично проходил через несколько проектов, где спать приходилось по два часа в день в течение месяца, и могу точно сказать — это всё из-за неграмотного планирования."
Тут, вероятно, одно из другого и следует. Не понаслышке знаю, как не выспавшиеся менеджеры ставят задачи и что в итоге получается.

"Риск-карта — это таблица, в которой указываются все риски, разбитые по категориям, их шанс случиться, урон для проекта, а также план по их нейтрализации."
Зачем нужны цифры, если они всё равно заполняются субъективно? Так можно и просто две категории оставить - "как-нибудь выкрутимся" и "abandon ship!".

А так-то в целом, да, жду второй части.

Ответить
Развернуть ветку
Павел Скиннер

Законспектировал.

Ответить
Развернуть ветку
Никита Видинеев

Спасибо за отличную статью!

Ответить
Развернуть ветку
Oleg Borisov

Великолепная статья, спасибо!

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Miroslav Tsarev

Материал отличны! Спасибо.
Неделя прошла, специально зашел проверить не пропустил ли что.
Фидбеки хорошие, людям нравится, вторую часть еще писать не передумали или просто времени нет?

Ответить
Развернуть ветку
Peter Fomichev
Автор

Привет!

Не передумал, но пока не получается написать ее хорошо. А публиковать то, что мне заведомо не нравится я не хочу :)

Ответить
Развернуть ветку
Sergej Ivanov

Тоже жду вторую часть, проверяю vc каждый день

Ответить
Развернуть ветку
Maxim Kuznetsov

Классная статья, поскорей бы вторая часть)

Ответить
Развернуть ветку
40 комментариев
Раскрывать всегда