Спорю с постом «Почему проектный подход больше не работает?»
Пост попался мне в Сетке и у меня бомбануло.
Вот он целиком:
Почему проектный подход больше не работает? 🚀
У нас есть клиенты, с которыми всё началось с одного проекта. Потом подключилась поддержка, развитие, и вот ты оглядываешься — а вы уже работаете вместе 5+ лет. 😳
Казалось бы, всё идёт хорошо: команда знакома с продуктом, клиенту нравится, что у нас вся экспертиза под рукой, а на вникание в процессы не тратится лишнее время. Зачем что-то менять?
❗️Но вот интересный момент: проектный подход в таких случаях уже не работает. Более того, он становится причиной большинства проблем.
📌Почему проектный подход перестает работать?
Проект — это конкретный объем задач, результат которых можно измерить в конце: «Вот вам ТЗ, вот разработанный проект». Но когда вы с клиентом вместе годами, задачи никогда не заканчиваются.
Вот что происходит:
🔹 Потеря знаний.
За 5 лет состав команды неизбежно меняется. Люди уходят, приходят, а вместе с ними уходит и накопленная экспертиза.
🔹Растущая сложность.
Продукт клиента развивается, в нём появляются новые компоненты системы, зависимости, интеграции, требования. А проектный подход слишком жёсткий, чтобы успевать за изменениями.
🔹Изменение приоритетов.
Когда вы планируете один проект, всё более-менее стабильно. Но за несколько лет потребности бизнеса клиента могут полностью измениться. Тут становится очевидно: чтобы развивать такой продукт, нужно работать по-другому.
📌Продуктовый подход: в чём разница?
Проект — это работа на результат в рамках фиксированных сроков.
Продукт — это процесс постоянного развития, где главное — ценность для пользователя.
Если совсем упростить: проект заканчивается, продукт — никогда.
📌Ключевые отличия:
• Команда. В проекте может быть временная группа специалистов, а в продукте — стабильная кросс-функциональная команда.
• Цели. Проект нацелен на выполнение конкретного объёма задач, продукт — на достижение бизнес-результатов.
• Процессы. В проекте есть начало и конец, в продукте — циклы постоянного улучшения.
📌Как мы трансформируем команды из проектных в продуктовые?
У меня есть несколько советов, которые показали себя максимально эффективными:
🔹 Создайте единую базу знаний с клиентом по продукту.
Фиксируйте всё: архитектуру, процессы, фичи. База знаний спасёт в случае ухода ключевых специалистов. И заведите туда обязательно клиента — это повысит доверие >и упростит совместную работу. Кстати, за её ведение не стесняйтесь брать деньги: это полезно всем.🔹Стирайте границы между командами.
Чем больше точек соприкосновения, тем лучше. Приглашайте ключевых сотрудников клиента на свои внутренние церемонии: планирование спринта, координации, ретро. >Это сделает работу прозрачной и укрепит партнёрство.🔹Проводите онбординг.
При смене сотрудников новый специалист должен быстро войти в контекст. Онбординг — это обязательный этап, где вы рассказываете о проекте, продукте и его целях, >знакомите с процессами, продуктом.🔹Создайте обучающий курс и проверяйте знания регулярно.
Разработайте внутренний обучающий курс. Включите в него тесты и регулярно проводите экзамены, которые будут проходить не только новички, но и «старички» >команды. Это помогает сохранять актуальность знаний, вовлекать всех в процесс и держать команду в отличной форме.🔹Инициируйте воркшопы и церемонии для улучшений.
Включите в свой процесс регулярную задачу: раз в заранее определенный период проводите внутренний воркшоп, на котором команда генерирует идеи по улучшению >продукта. Затем структурируйте предложения и обсуждайте их с клиентом. Это не только прокачает продукт, но и покажет вашу вовлечённость и экспертность.📌Почему это работает?
Продуктовый подход — это не просто новый формат работы, это возможность построить с клиентом долгосрочное партнёрство.
Такой подход создаёт доверие. Клиент видит, что вы не просто выполняете задачи, а действительно заботитесь о его продукте.е просто новый формат работы, это возможность построить с клиентом долгосрочное партнёрство.
К автору поста не имею никаких претензий, наверняка он прекрасный человек; ниже я критикую исключительно суть и содержание поста в его исходном виде.
И начинается он с кликбейта:
«Почему проектный подход больше не работает?»
Но он работает; утверждение автора сродни следующему: «я купил машину — ходьба пешком больше не работает 🙅♂️». Чтобы объяснить, почему конкретно в деятельности автора проектный подход не работает, нужен контекст: что за отрасль, что за клиенты, какие проекты/продукты вы делаете. Тогда — да, можно обсуждать состояние проектной деятельности в конкретной отрасли, или с конкретным типом компаний/заказчиков, и т. п.
«проект — это конкретный объем задач»
Вообще не везде и совсем не всегда; в общем виде «проект» — это организованные усилия команды по достижению результата. Если вы придете к заказчику и скажете «вот, мы выполнили все описанные задачи, дайте денег», то он закономерно спросит вас о результате. И если его нет — назовет вас плохими словами и денег не даст.
Цель проекта — достижение некоторого результата, обычно оговариваемого заранее. Какие для этого нужно выполнить задачи и в каком объеме — вопрос технический и нормального заказчика волновать не должен.
«когда вы с клиентом вместо годами — проект никогда не заканчивается»
В таких ситуациях это скорее серия или программа проектов, просто автор почему-то предлагает перестать к ним так относиться. Серия проектов — это когда «выход» одного проекта становится «входом» другого, программа — это когда проекты явно не связаны, но работают на выполнение единой стратегической задачи. У программы есть свои эк. показатели и ресурсы, которые распределяются между проектами; часть проектов не доживает до финиша, но эффект от реализации программы должен в целом работать на стратегическую цель заказчика. У программы свой руководитель, у каждого проекта внутри — свои, они подчиняютcя руководителю программы.
«потеря знаний/растущая сложность/изменение приоритетов»
Знания нужно фиксировать на любом проекте, потому что ключевой сотрудник может уйти в любой момент — в жизни всякое случается; про растущую сложность и «жесткость» проектного подхода не понял — на самом деле правила можно менять, если изменились обстоятельства, в том числе правила проектной работы и взаимодействия с заказчиком.
Про изменение приоритетов тоже вода какая-то: они и в процессе выполнения первого проекта могут поменяться несколько раз. Нужно работать со спонсором проекта и вовремя отслеживать изменения. См. фреймворк OMG Essence, там на верхнем уровне есть три области интересов: стейкхолдеры(=заказчики), решение, управление. Приоритеты «висят» в области стейкхолдеров.
«Продукт — это процесс постоянного развития, где главное — ценность для пользователя.»
Тут у меня подгорело седалище из-за пренебрежительного отношения к определениям. «Продукт — это процесс», серьезно?
Для заказчика продукт — это предсказуемый способ зарабатывать деньги на рынке. Продукт можно придумать один раз, а продать — много раз, разным покупателям. Его для этого и делают. И именно в этом разница продуктового и проектного подходов: проект — каждый раз уникальное мероприятие, каждый раз новый набор требований и ограничений, продукт — один раз сделали, много раз продали. Продукт делать дороже и дольше, потом его нужно улучшать и менять — это сложнее с физическими продуктами и проще с софтом. По-прежнему справедливо мое утверждение, что продукт разрабатывается путем реализации серии проектов.
Продукт нужен, чтобы зарабатывать деньги, а не «предоставлять ценность для пользователя». Простая проверка: из пары стратегий «давать ценность и не зарабатывать деньги» и «зарабатывать деньги и не давать ценности» предприниматель выберет последний.
«Проект заканчивается, продукт — никогда»
Всем так хочется, но так не всегда бывает. Продукты могут устаревать, утрачивать конкурентные позиции и т. п. — вполне себе заканчиваются. Проверка: попробуйте составить план получения выручки за счет «продукта, который никогда не заканчивается» — получите бесконечное количество денег. Неплохо, но в жизни не встречается.
Команда/Цели/Процессы...
В проектах тоже может быть стабильная кросс-функциональная команда, все ок. Цели — снова ошибка про «конкретный объем задач», а не достижение цели проекта. Про продукт верно, цель — достижение бизнес-результатов, если конкретнее, то — прибыль на жизненном цикле.
Переход из проекта в продукт...
...возможен, если клиент строит продуктовую компанию и понимает, что это значит. База знаний тут абсолютно ни при чем, ее можно создать и в рамках любого проекта. «Границы между командами», онбординг и прочее — все справедливо и для проектов.
«Включите в свой процесс регулярную задачу: раз в заранее определенный период проведите внутренний воркшоп, на котором команда генерирует идеи по улучшению продукта... (это) прокачает продукт и покажет вашу вовлеченность и экспертность»
«Прокачать продукт» — значит, улучшить общую продуктовую экономику. Для этого нужно посчитать, какую прибыль на жизненном цикле продукт принесет компании, и принять это за базовый сценарий. После этого любые предлагаемые командой идеи должны эту прибыль увеличить — путем изменения одного из влияющих на нее факторов. Делать это нужно, в идеале, во время разработки продукта, именно в этот период можно существенно повилять на продуктовую экономику. Когда продукт на рынке — возможностей гораздо меньше и они обойдутся дороже.
«Продуктовый подход — это... возможность построить с клиентом долгосрочное партнерство.»
Вообще, рыночная продуктовая компания никогда не отдаст основную компетенцию — делать и улучшать продукт — на подряд. Это просто очень рискованно: подрядчик почему-то решает прекратить сотрудничество — и привет, продуктовая работа закончилась, нас сожрали конкуренты. Продуктовая компания действительно может отдавать кусочки работы или даже фрагменты продукта на аутсорс — но ни в коем случае не весь продукт, и тем более не весь продуктовый процесс. Или такая компания быстро закончится.
«Клиент видит, что вы не просто выполняете задачи, а действительно заботитесь о его продукте.»
Все еще справедливо в отношении проекта. Хороший проектный подрядчик беспокоится не за состав работ и их выполнение, а за получение требуемого результата. Для этого нужно хорошо понимать, а как именно в рабочую цепочку заказчика встроится результат проекта. А это как раз хороший первый шаг к пониманию того, что такое продукт ;-)
Вывод: автору поста было бы здорово получше изучить проектный подход и применяемые в нем методики. Проекты и проектный подход никуда не денутся, по-прежнему работают и в жизни встретятся не раз.
Мне нравятся подходы и инструменты Ивара Якобсона — конкретно под проекты подходит OMG Essence, про него есть доклады на ютубе. Продуктовый подход — сложная штука и сильно отличается от того, что описывает в посте автор.
Немного в защиту автора — из поста сложилось ощущение, что речь идет все-таки не о проектном подходе в целом, а о какой-то отраслевой/доменной специфике, или даже конкретно о специфике подхода в компании автора. Чтобы это было очевидно — нужно было исходный пост обогатить фактурой, дать контекст и конкретные примеры. Тогда пост стал бы полезным, можно было бы за что-то зацепиться, что-то обсудить, а не только до понятий и незнания матчасти докопаться, как я сделал в этом посте.