9 заметок с тегом

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

Игра «Проект»

В электронном учебнике «Управление проектами, людьми и собой» вышла новая игра! Учитесь рулить проектом, не рискуя настоящими деньгами и репутацией. Смотрите видео и попробуйте сыграть лучше, чем Николай Товеровский:

Игра работает без подписки на книгу — ищите её в демоглаве:
https://bureau.ru/books/fff/demo/17

Чтобы играть лучше, подпишитесь на книгу:
https://bureau.ru/projects/book-fff/

14 февраля   игра   книга   управление проектами

Фалькон Хеви

Поздравляем Илона Маска с запуском Фалькона Хеви. Если будем переиздавать книгу по управлению, с удовольствием закрасим новые ракеты в главе о маршруте проекта:

Разворот из книги «Управление проектами, людьми и собой»

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

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

Для построения маршрута проекта используйте принцип „думать глобально, действовать локально“.

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

7 февраля   маршрут проекта   управление проектами

Кто исполнитель

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

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

Тщательно выбирайте людей в команду до старта проекта, как это делал полярный исследователь Руаль Амундсен:

Один лоцман сказал, что корабль Амундсена — это самое поразительное из всего, что он видел. «Приказов не отдавали, но все, казалось, точно знали, что нужно делать».

Хелмер Ханссен писал, что он «попал не к строгому капитану, не к начальнику, а будто бы к отцу».

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

«А на корабле нет места для тебя, — сказал Амундсен, кусая губы. — Собирай вещи и проваливай».

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

Роланд Хантфорд. Покорение Южного полюса. Гонка лидеров. Манн, Иванов и Фербер, 2012

Критерии

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

Лояльность — вера в проект, менеджера и команду. Фундаментальный критерий. Если исполнитель не верит в проект, его польза может оказаться не просто нулевой, а отрицательной. Чем опытнее неверующий исполнитель, тем сильнее он может навредить. Людей с низкой лояльностью брать в команду опасно. Уровни:

−5 заклятый враг — 0 планктон — 5 соратник

Активность — умение взять инициативу и по-настоящему решить проблему. Может свернуть горы. Если исполнитель умеет «сделать», он может быть полезен даже, если базовый навык у него невысокий. Уровни:

1 тюфяк — 5 полководец

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

1 ребёнок — 5 профессионал

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

1 слабак — 5 маг

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

Примеры исполнителей

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

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

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

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

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

Турбированный новичок
Прекрасный кандидат на рост. Если турбонапора хватит, сможет быстро прокачать навык и стать ценным кадром.

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

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

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

Тест

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

Переставить ссылки в подвале сайта — хорошая маленькая задача для верстальщика. Сверстать пару рыбных блоков — плохая. Рыба не попадёт в реальный продукт, и проверка будет некачественной. В Дизайн-бюро Артёма Горбунова используют тест для проверки внешних технических команд.

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

Календарь дел

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

Суть

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

Технология

☞ В примерах ниже используется стандартная программа МакОС «Календарь», но метод не зависит от программного обеспечения — подойдёт любой инструмент, где можно планировать события в календаре.

Заведите календарь и планируйте там все задачи. На каждую задачу выделяйте время, которое планируете на неё потратить.

Если задача сделана, отметьте её знаком «+». Если задача отменена, и делать её не нужно, отметьте её знаком «-»:

Если время на исходе, а задача всё ещё не сделана, остановитесь и примите решение, как поступить. В вашем распоряжении три варианта: 1) забить, 2) попилить ещё, то есть добавить время, 3) пофлексить.

Забить

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

Если решили забить, поставьте в задаче крестик:

Попилить ещё

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

Если решили попилить ещё, поставьте крестик и запланируйте новую итерацию. Это поможет сохранить контроль:

Пофлексить

Пофлексить — значит придумать, как сделать задачу за отведённое время и без потери качества. Хитрость флекса в упрощении решения. Это самый хороший вариант — задача решается и решается в срок. Если придумали как пофлексить, доделайте и поставьте «+».

Пример календаря с большим количеством дел:

Результаты

Использование календаря дел имеет ряд полезных последствий.

План дня

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

Закрытый список

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

Оценка задач

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

Инкапсуляция ада

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

Хитрости

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

Пример группировки задачи из книги Тима Фериса «4-часовая рабочая неделя»

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

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

Чтобы вводить крестики установите раскладку Бирмана.

Ошибки

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

Недостатки подхода

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

Репер Фейс не планирует

Инструменты для ведения дел в календаре несовершенны. Неудобно делать задачи меньше получаса. Ставить плюсики, минусики и крестики — морока. Легко забыть отметить сделанную задачу, и она повиснет в неопределённом статусе. В примере календаря с большим количеством дел есть такая повисшая задача:

См. также

Текущая инициатива

18 декабря   управление проектами   управление собой

Краткая инструкция по сделыванию для разработчиков

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

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

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

2. Поймите задачу. За задачу отвечаете вы, поэтому на вашей совести задать все вопросы, запросить все материалы, оговорить все нюансы по задаче. Если чего-то не хватает или вы не верите, что справитесь — не берите задачу. Если взяли — сделайте, не смотря ни на что.

Чтобы понять задачу задавайте вопросы:

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

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

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

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

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

5. Оставьте запас времени. Не планируйте впритык. Что-то обязательно пойдёт не так. Вы столкнётесь с неуловимым багом, дизайнер десять раз попросит подвинуть кнопочку, проект не соберётся, комп заглючит, свет отрубят. Заложите 20% запаса в срок, он вас спасёт.

6. Сделайте. Добейтесь результата в срок. Если не будете укладываться — придумайте, как упростить и предложите упрощение дизайнеру. Знать, что не успеваете и молчать — отстой. Упростить и не согласовать с дизайнером — отстой. Не успеть и молча продолжать делать — отстой. Ждать, что упрощение придумает дизайнер — отстой.

7. Сдайте. Утвердите работу у дизайнера. Он ваш клиент. Если он не сказал «ОК», вы не сделали, даже если вы всё запрограммировали и всё работает. Пока не сдали «пластилин» в ваших руках.

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

На выходе в день старта >> ваше понимание задачи (спецификация), дедлайн, набор контрольных точек — гвоздей.

В день дедлайна >> «ОК» от дизайнера и опубликованное в продукте решение.

P. S. Если всё-таки сорвали срок, признайте это как можно быстрее. Если дизайнер согласен работать с вами дальше, вернитесь к пункту 1. У вас должно возникнуть новое понимание задачи, новый дедлайн и новый набор контрольных точек.

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

3 декабря   инструкция   разработка   сделать   управление людьми   управление проектами

Срать в ячейки

Робине Тестар. Книга простых лекарственных средств. 15 век

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

Очевидный способ устранить хаос — найти каждому предмету своё место. Этот способ обладает недостатком: очень долго. Чтобы навести порядок мгновенно, срите в ячейки.

«Срать в ячейки» — универсальный приём организации хаоса. Любой бардак, разложенный по ячейкам, уменьшается на порядок. Метод и название подсмотрены автором в ЖЖ Артемия Лебедева:

nolar: Как сделать бардак самоприбираемым?
tema: Срите в ячейки.

В жизни

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

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

С десятками баночек и пакетиков детского питания будет проще иметь дело, если разложить их в коробки:

Внутри «ячеек» хаос сохраняется, им можно заняться позже:

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

См. также

Бесконечные банковские ячейки

2017   срать в ячейки   управление проектами

Гвозди в гусенице

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

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

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

У опи­сан­ных ситу­а­ций одна природа:

менеджер — лох, не прибили гусеничку.

Задача похожа на гусе­ницу, кото­рая изви­ва­ется всем телом как чер­вяк на ско­во­родке. Вероятность, что гусеница сама приползёт в наме­чен­ную точку в заданное время стре­миться к нулю. Чтобы сделать вовремя, гусе­ницу нужно при­бить «гвоз­дями», тогда она не сдвинется:

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

Свой­ства гвоздей

Конкретность

Гвоздь должен быть чёткой договорённостью. «Три макета к четвергу к 15:00» — хороший гвоздь. «Давай, чтобы на этой неделе всё было сделано» — плохой.

Несдвигаемость

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

Многоуровневость

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

Ритмичность

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

В жизни

Советский союз применял пятилетнее планирование в национальном масштабе с 1928 года:

Гугль применяет метод ЦКР (цель и ключевые результаты), планируя работу кварталами. Метод был внедрён Джоном Дором через год после основания Гугля и используется до сих пор:

Слайд из оригинальной презентации Джона Дора

В Дизайн-бюро Артёма Горбунова. Про­екты планируют понедельно, в конце каждой неделе демонстрация результатов клиенту:

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

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

См. также заметку о стоимости задач

Ошибки

В идеальном мире гвозди нужны исполнителю — тому, кто делает работу, а не клиенту — тому, кто принимает результаты. Хороший исполнитель сам прибивает гвозди, чтобы сделать первоклассную работу: «Николай, я предлагаю посмотреть промежуточные результаты 8-го, 14-го и 28-го мая. Когда тебе удобно?»

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

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

Кли­енту про­тивно прибивать гвозди, но лучше уж так, чем провалить задачу или проект. Так или иначе, гвозди должны быть забиты.

Одних гвоздей недостаточно для успешного проекта. Но без них провал практически гарантирован. Гвозди в гусенице — необходимое условие успеш­ного проекта.

См. также

Совет о гвоздях в гусенице

2017   гусеничка   управление проектами

Утверждение и уведомление

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

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

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

Уведомляют в трёх точках:

  1. Собираюсь что-то сделать — чтобы предупредить ошибку.
  2. Что-то сделал — чтобы другие участники знали, чего ждать.
  3. Получил результаты — чтобы распространить знания о продукте и гипотезах.

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

См. также

Тим Ферис Позволение плохому случаться (на английском)

P. S.

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

2017   управление продуктом   управление проектами

Фиксированный дедлайн в продуктовой разработке

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

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

〈...〉

Вдруг он ясно услышал, что бьют часы. Он вздрогнул, очнулся, приподнял голову, посмотрел в окно, сообразил время и вдруг вскочил, совершенно опомнившись, как будто кто его сорвал с дивана. На цыпочках подошёл он к двери, приотворил её тихонько и стал прислушиваться вниз на лестницу. Сердце его страшно билось. Но на лестнице было всё тихо, точно все спали... Дико и чудно показалось ему, что он мог проспать в таком забытьи со вчерашнего дня и ничего ещё не сделал, ничего не приготовил... А меж тем, может, и шесть часов било... И необыкновенная лихорадочная и какая-то растерявшаяся суета охватила его вдруг, вместо сна и отупения.

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

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

Как фиксировать дедлайн при работе с продуктами

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

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

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

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

Дополнение

Бейскемп разрабатывают циклами по шесть недель

2017   дедлайн   продукт   проект   управление проектами