Python conf in Kharkiv, Nov 16 with Intel, Elastic engineering leaders. Prices go up 21.10

10 шишек на одном проекте. Опыт PM’а

Как говорится, не ошибается только тот, кто ничего не делает. РМ’ы, увы, ошибаются и делают это с размахом ;)

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

Все имена и названия — вымышленные. Любое совпадение случайно.

О проекте

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

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

Старт

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

Также стало известно, что система уже «кое-как» сделана другими подрядчиками, назовем их команду FIM. Этим «кое-как» клиент Епифан сильно недоволен. Со слов Епифана стало также известно, планируется весь проект передать на разработку нам и полностью прекратить сотрудничество с FIM, как только мы, новая команда (назовемся WOW), будем готовы вести проект самостоятельно. Нам предстояла передача знаний, и первым условным заданием на старте было покопаться в коде, посмотреть, что же там коллеги из FIM сделали, как обстоят дела в архитектуре.

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

Шишка 1. РМ должен выяснить до мельчайших деталей, почему клиент решил сменить провайдера

Это инструмент РМ’а в будущей работе. Зная детали и учитывая их, можно не допускать тех же ошибок, из-за которых клиент решился на смену команды. Мы четко знали, что будем пилить проект самостоятельно, как только будем готовы. На том этапе у меня не возник вопрос, а как определить готовность, и одинакова ли она у нас с клиентом?

Шишка 2. РМ’у необходимо заранее выяснить ожидания клиента от команды и него самого

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

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

Передача знаний

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

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

Каково же было наше разочарование, когда мы узнали, что ребята из FIM не очень-то хотят эту передачу делать и всеми возможными способами пытаются замедлить процесс. Они ссылались на то, что нет времени, так как у них много задач для разработки, есть сроки и обязательства перед клиентом. Мы в какой-то момент стали заложниками ситуации: с одной стороны, нам нужно как можно быстрее закончить передачу знаний и подхватить проект; с другой стороны, команда FIM пилит клиенту фичи, которые он же от них и требует. В итоге команда FIM уполномочила Solution Architect’а передавать нам знания о проекте по 2-3 часа в день.

Шишка 3. Приоритеты и цели должны быть синхронизированы и понятны для всех участников проекта

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

Шишка 4. Ориентироваться нужно на то, что лучше для проекта и клиента, а не на то, что лучше вам

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

Процессы

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

Через несколько итераций на меня обрушилась буря негодования со стороны Епифана, который не понимал, что происходит. Посыпались вопросы: «А где же демки работающего продукта после каждого спринта, как было ранее? А что это за задача „investigate фичи“? А? Что за юнит-тесты? А почему тестировщик столько времени тратит на какие-то документы тест-стратегии и тест-кейсов? Почему он не может просто проверить, что все работает? Почему я должен платить за то, что ваш разработчик устанавливает себе локальную среду разработки?» и другие вопросы в том духе.

Сказать, что я был удивлен — не сказать ничего. Я тут же принялся объяснять клиенту, почему так и никак по-другому, зачем это надо и что это нам даст. Откровенно говоря, начал отвечать на вопросы клиента «реактивно».

Шишка 5. То, что очевидно вам, не очевидно другим

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

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

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

Шишка 6. Процессы должен устанавливать тот, кто несет ответственность за результат

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

Клиентоориентированность

Мы всей командой WOW старались помочь клиенту. Были дедлайны, коммитменты, отношения с заказчиком, и это выходило на первый план. Клиенту надо успеть пятилетку за три года, погнали!

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

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

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

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

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

Доверие и подчинение

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

В письме был очень простой запрос от клиента: не мог бы я предоставить ему доказательства, что все часы, отработанные командой за все время на проекте, были где-то подтверждены им лично или коллегами с его стороны. У нас были выстроены процессы еженедельных и ежемесячных репортов, где все было достаточно прозрачно расписано: кто чем занимался, сколько времени потратил на ту или иную задачу. Клиент, имея на руках все отчеты за все время работы, запросил новый с доказательствами, где и кто подтверждал чуть ли не каждый час работы команды. Обычно на проектах такого масштаба этого никто не делает. Такой запрос звучал для меня как «А можно наконец-то проектного менеджера добавить в команду?».

Затем последовали длительные сборы отчетности, кошмарные переговоры со всеми и вся и вопросы от клиента вроде «А кто этот час аппрувил?». Было много неясностей, и я нашел огрехи в своих же отчетах, но в то же время было ясно одно: доверие клиента утеряно.

Шишка 8. Как только клиента начинают заботить мелкие задачи или отчеты, значит что-то не так с доверием

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

Шишка 9. Не допускайте двойного подчинения

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

Пока внезапно решения Покахонтас и Мариванны не стали конфликтовать друг с другом. Мариванна поручила очень важную задачу, мы делаем. Покахонтас говорит давайте-ка сделаем вот эту задачу очень срочно. Сделали. Через неделю приходит Мариванна и говорит, что вы не сделали ту задачу, которая была самой срочной. В глазах Епифана мы просто провалили дедлайн. Я считаю, что если бы я сразу определил такой риск, то смог бы договориться с клиентом об одном человеке, который бы и принимал решения, а не МариХонтас, из-за которого пришлось набить очередную шишку. Или вообще сделать stakeholder matrix и engagement strategies. Тогда точно таких бы проблем не возникло.

Выводы

В итоге клиент Епифан решил остаться с FIM. Могу с уверенностью сказать, что я, как РМ, очень сильно завалил проект, несмотря на все усилия. Но этот опыт помог проанализировать мои же ошибки, сделать выводы и стать сильнее!

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

Этот проект позволил мне взглянуть по-другому на свою работу. Как одно из следствий — получил PMP сертификацию (об этом можно почитать статью Как я готовился и сдал PMP Exam с результатом «Above Target» по PMBoK‎ 6th Edition), разобрался в эффекте Даннинга-Крюгера. Могу точно сказать, что бесконечно благодарен этому опыту.

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

Keep managing and let’s rock!

LinkedIn

66 комментариев

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

Интересно. Есть о чем подумать. Что увидеть. Благодарю за мысли.

Спасибо за статью. Подскажите — а как работали с рисками в этом кейсе?

Благодарю за коммент.

а как работали с рисками в этом кейсе?

Этот вопрос можно расписывать в отдельную статью ;) Если вкратце,то выявили -> задокументировали -> оценили -> придумали стратегию -> трекаем.

На каком шаге была ошибка?

та на любом можно найти ошибку. Идеального процесса не существует.

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

Спасибо за фидбек, много очевидных ошибок было допущено.

команды WOW на проекте было

Около 15 человек.

сколько активно работало в FIM на момент передачи?

Активно работал с нами FIM архитектор и еще около 5-7 ребят from time to time.

Спасибо за возможность учиться на чужих шишках ). Можно уточнения по ряду вопросов:

1. Модель оплаты.
По каким мотивам была принята модель fixed price? Запрос клиента? Собственное предположение? Fixed price кажется абсолютно необоснованной при продолжении чужого проекта.

2. Передача знаний.
Обсуждалась ли передача проекта (в том числе знаний) с клиентом заранее?
Т.е. это был тихий саботаж FIM, при том, что клиент сообщил, что «все будет», или согласованием через клиента стали заниматься после проблем с передачей знаний?

Спасибо!

Спасибо за коментарий!

1. Модель оплаты.
По каким мотивам была принята модель fixed price?

Если прочитаете внимательнее, то увидете что модель как раз не Fixed Price, a Dedicated Team&

Обсуждалась ли передача проекта (в том числе знаний) с клиентом заранее?

Конечно обсуждалась. Более того, обсуждалась между тремя сторонами.
Епифан + Мы + FIM на общих митингах обсуждали план передачи.

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

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

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

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

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

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

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

Да я собственно, никого так и не называл.
Поделился своими мыслями и опытом, дураков нет.

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

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

И причем тут руководитель? :)
Просто кто-то переоценил свои силы, не проработал все риски и на выходе получил закономерный результат.

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

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

поставил вас на проект, наделил полномочиями, потом много месяцев наблюдал за вашими шишками

Все было не так. Мы плотно вместе работали и вместе пытались выбраться.

Интересна была бы его точка зрения

Ну этого я не могу написать, а там много интересного было ;)

Значит, это ваши общие с ним шишки и уроки, правильно?

Они конечно же пересекаются.

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

Не торопись с выводами. Быть PM в аутсорсе и быть им в продукте пожалуй две большие разницы. В продукте не будет «хочу-угодить-клиенту» стратегии (там не посредника). Идеально такого не должно быть и в аутсорсе, но по ходу этим грешат.

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

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

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

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

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

Шишка #7 заводила в бесконечный цикл переспоривания, обе стороны злые, доверия нет...

Все мы где-то в глубине «Епифаны».

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

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

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

один из примеров. когда проект продается по фиксд прайс клиент не просто лезет под капот — его интересует каждый рублик, каждый пук и чих. для чего есть специальный артефакт — basis of estimates. а что за божественный клиент, которому просто ставишь ценник — и побежали, я бы хотел так хоть разочек =)

я бы хотел так хоть разочек =)

Я уверен, все получится!

Отличная статья. Не только PMу полезно почитать.
Поржала с имён))

Зоя, спасибо!
С именами много правок было и в конце концов, когда определился, я тож поржал если честно,

Отличная статья, пишите еще.

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

З одного боку був хитрий клієнт, який звик, що йому ці хлопці з України все зроблять за помірні гроші — вони вже зробили проекти по fixed price, зможуть і тут

Далі підключаєтся українське керівництво, яке доручає цей великий проект вам.

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

Давайте перекладемо слово «великий» на людську мову — «якщо ми потянем цей проект, то заробимо купу грошей, тому як хочеш, але клієнта треба задовольнити» :) something like this

Далі це пояснує купу ваших рішень, неможливість чітко сказати «ні» чи послати клієнта.

Потім вам декілька разів конкретно сідають на шию, і ви мовчки робите свою справу далі.

Загалом якби все вийшло, то десь на батьківщині Єпіфанія вони б один одному розказували, які ці українці прикольні і дешеві, і обскакали там якусь банґалорську контору

Власне вся українська IT-галузь виросла з купи таких історій, де якось вдалось пропетляти і не завалити проект. Зрештою з маленьких проектів виросли до великих. Але таких ласих «великих» клієнтів, яким точно треба догодити — це було в кожного. Тут не пощастило, але буває.

Якби ви могли чітко казати «ні» клієнту і ставити рамки, то все б завершилось нормально, абе клієнт би від вас пішов.

Але чи або в кінці? :-)

«але» :)

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

Якби ви могли чітко казати «ні» клієнту і ставити рамки, то все б завершилось нормально, абе клієнт би від вас пішов.

Раздел о клиентоориентированности как раз об этом.
Мало сказать просто нет.
Более того, сами клиенты учат говорить нас «Да, но...», чем «Нет, но...». Смысл один и тот же, воспринимается по разному.

Мало сказать просто нет.

Именно. Нужно еще обосновать и убедить клиента почему так, а не иначе и как клиенты будет лучше. А клиент почти всегда неправ.

Я слишком поздно понял, что клиент, который работал с нами по модели fixed price, привык просто получать результат и знать, сколько он за это платит. Он никогда не заглядывал «под капот». Ему было все равно, что и как мы делаем, на что тратим усилия, сколько человек в этом задействованы, какой их уровень, с какими трудностями мы сталкиваемся, какие митинги проводим, если мы все делаем в срок и в рамках бюджета. Тут фокус сместился, клиент начал платить за специалистов и, знакомясь с новой моделью сотрудничества, хотел убедиться, что каждая минута была потрачена эффективно.
В итоге клиент Епифан решил остаться с FIM.

А с FIM он по какой модели работал?

Fixed Price. Они нам даже как-то сами говорили, что Епифан так раздул скоуп, что сами страдают от убытков.

Классная, честная статья и интересная графика, спасибо!
Была ли на проекте выделенная роль по работе с требованиями? Stakeholder matrix, business need analysis, requirements prioritization, backlog/scope management — это косвенные задачи для Project Manager роли, особенно в dedicated team для product development. Как предложение:
Шишка 0 — добавить бизнес-аналитика в проект/продукт для работы с требованиями

Спасибо за фидбек.

Была ли на проекте выделенная роль по работе с требованиями?

Да, была. Обычно этим занимались Пакахонтас или Мариванна. Так что Шишка 0 имеет место быть.

Классика жанра:

Клиент: — Я ничего в этом не понимаю, вы — специалист, вот вам деньги, чтобы вы сделали эту работу профессионально
Исполнитель: — Вот так нужно сделать.
Клиент: — Я не согласен.

Именно так! Классика :)

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

Я очень рад, что труды оценены! Спасибо.

Отличная статья, спасибо за честность и откровенность в описании фейлов. Эдакий FuckUp пост.

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

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

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

Так что от сообщества плюсы в карму ловите).

ахаха, супер! Спасибо, карма поправлена ;)

у вас были ранее выстроены хорошие отношения с клиентом

Валидное замечание, вполне возможно так и было.

Отличная статья! После прочтения, первая мысль была C’est la vie!

Дякую за статтю.

Думаю, багато хто проходив через подібні ситуації, коли другу\свату\брату треба виконати якусь задачу і професійний підхід ігнорується, бо є високий взаємний кредит довіри у добре знайомих людей.

Біля п’яти років назад я домовився (на словах) зробити хорошому знайомому веб-магазин, але не розрахував свої сили та ресурси, в результаті витратив і свій і його час, стосунки з ним зіпсувались. Це для мене послужило хорошим уроком, щоб в подальшому професійний підхід завжди був в топі пріоритету над всім іншим в подібних ситуаціях.

Благодарю за коммент.

Це для мене послужило хорошим уроком

Уроки они такие :)

Респект що відкрито розказуєте про свої помилки. Ато тут майже всі пишуть тільки які вони класні

Супер, я рад что оценили!

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

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

Спасибо! Мы всей командой правда старались и делали the best we can.

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

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

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

По сути, сами же создали себе и команде проблемы в начале.

PMP решило проблемы коммуникации в будущих проектах?)

РМР не серебряная пуля от всех болячек РМа, но помогло существенно :)

Спасибо, статья — супер!

Подписаться на комментарии