Comments 26
Таков мой опыт. Я наблюдала (и участвовала) в ситуациях, когда наобещаем вначале, а по итогу, не попадаем практически ни в одно обещание. И в результате все недовольны: заказчик, который ожидал другой результат, или этот результат но за другие деньги/за другое время; команда, которая работала сверхнормы, или с постоянно меняющимися требованиями и тп. Ваш пример очень интересный, после того как ввязались успешно разбирались?
Бывает, что Заказчик настаивает на своих хотелках, даже если они нежизнеспособны. Аргументирует это тем, что он платит деньги, поэтому он прав, а мы должны делать то, что он говорит.
Умом я понимаю, что Вы пытаетесь сказать.
Но менее искушённый читатель может подумать, что Вы ведёте речь о подходе "заказчик дурак, я лучше знаю, что лучше для него".
Я бы посоветовал это как-то перефразировать.
Бывает, что Заказчик высказывает следующую претензию: вы должны все знать, досконально знать, как работает решение из коробки. Или вы должны продумать значение каждого параметра, за что он отвечает, и как его применить. Что с этим делать? Здесь у меня, к сожалению, нет четкого совета.
Предпроектная аналитика тут нужна именно для этого.
Но она мертва.
принцип сначала ввязаться, потом разберемся.
Что-то напоминает. Лучше всё же разобраться и подготовиться.
На мой взгляд, о том, что возможно сделать и за какой срок, стоит говорить максимально правдиво и обдуманно. Если есть сомнения, то лучше взять паузу, обсудить со специалистами в компании. И уже после этого договариваться о функционале, который может быть реализован. А если остались спорные или непонятные моменты, их можно вынести в ограничения.
Проблема в том, что если называть реальную стоимость и сроки, то заказчик уйдет к другой фирме (которая потом также сорвет сроки и будут что-то решать со стоимостью), а то и вовсе откажется от проекта. Проблема может усугубляться тем, что премия менеджера по продажам может не зависеть от реализации проекта.
Аналогия. Возьмем двух перекупов. Первый продает убитую тачку со скрученным пробегом, не работающими тормозами и заклеенным индикатором "check engine". Второй продает тачку, за которой был хороший уход, без серьезных проблем и с небольшим пробегом. Тачки оного года выпуска, но цена у второго сильно дороже. Покупатель не понимает, почему так дорого, если точно такая же стоит сильно дешевле и покупает у первого. Да возможно второму тоже удасться когда-то найти покупателя, но устойчивый бизнес на этом не построить, поэтому продавцов первого типа полно, а вторых можно сказать не существует.
Дело не в токсичности заказчика, а в наличии других аутсорсеров, которые толи не умеют оценивать сроки, толи держат разрабов в рабстве, толи специально их занижают, чтобы потом продать заказчику доработки. Заказчик высылает ТЗ в 10 разных компаний и смотрит на суммы. Доказать что твоя компания дает самое лучшее предложении, при том, что у восьми других дешевле довольно сложно.
По моему опыту работы аутсорсе, там это там никак не лечится. Разрабы могут избежать этой участи перейдя в продуктовые компании.
Проблематику понимаю.
В нашей сфере я использую следующие способы. Если позволяет ситуация, предлагаю начать с MVP. На этапе проработки MVP мы покажем, как мы работаем. Это Заказчику позволяет наглядно увидеть, за что он платит. И после реализации поймем работаем ли дальше вместе или нет.
Детализирую скоуп работ и вместе с Заказчиком обсуждаем, какие работы можем исключить. Или, например, с целью уменьшения бюджета, часть работ Заказчик может взять на себя.
Бывает ещё такая ситуация: продажники продали что-либо клиенту, не уточнив или не правильно поняв требования и возможности. И вот заказ спускается в разработку, но в ранее утверждённом виде он не реализуем. Либо конкретным людям от Заказчика, которые будут работать с системой, нужно "немного не то", что было договорено "большими дядями". Вроде бы факап сейлов, но деньги заплачены, бумаги подписаны - приходится "что-то " делать.
Спасибо, за кейс. Что бы такого избежать, на этапе оценки стоит привлекать спецов. Даже если сейл уверен в своих знаниях, валидация со стороны команды не будет лишней.
Еще момент, это закладывать риски, сколько закладывать зависит от первоначальных вводных: насколько вам знаком Заказчик, насколько есть опыт в сфере, и не забывать про команду - кто это будет реализовывать. Это сложно, но возможно.
Еще хочется отдельно отметить, про определение стейкхолдеров. Есть кто платит, а есть кто будет пользоваться. "Большие дяди" о которых вы говорите, скорей всего являются спонсорами и вероятно они озвучивают бизнес требования. Стоит выявить у Заказчика тех людей, которые будут предъявлять функциональные требования.
Если заказчик это крупный концерн, то "достучаться" со стороны разработчика до конечных пользователей часто практически не реально. В лучшем случае это будет менеджер цеха (или нескольких). И вполне может быть, что пользователи вообще не в его подчинении, а от какой- нибудь фирмы-субсубподрядчика. И т.д. И лучшее, что может сделать этот товарищ, это собрать список пожеланий от разных смен и передать наверх по испорченному телефону. А там по цепочке. Ни о какой аналитике тут уже не идёт и речи. Если пожелания одно другому не противоречат, уже хорошо. А бывает всякое..
Все это сводится к одной фразе - кто не рискует, тот не пьёт шампанского!
Действительно, степень риска по каждой из осей суть величина, обратная определённости. Собственно, прибыль распределяется пропорционально градиенту риска по той или иной (у кого где компетенция) оси.
Будете слишком бессеребренны - в цепочку к вам встанет MITM, слишком осторожны - вас обойдёт более бесшабашный или более наглый, слишком самоуверенны - схватите куш, но половину потом отдадите врачам или в спортзале (да, у них тоже свой градиент), либо за это заплатят Ваши дети отсутствием внимания и платными репетиторами.
В целом этот закон обмануть нельзя - можно только обменяться на коротком промежутке времени тем, что менее важно вам на то, что менее важно другому.
А еще бывает, что заказчик считает что с его стороны при смене его основного ПО не потребуется ресурсов, и один два человека с его стороны на проекте все посмотрят, а потом сразу все 300 начнут работать.
О да! Выделить рабочую от заказчика этот бывает тот еще квест. При чем даже если людей выделяют, то часто внедрение нового ПО идет в дополнение к основным обязанностям. Тем самым люди перегружаются, ничего не успевают, отмахиваются от внедренцев.
Об этом стоит говорить с Заказчиков при старте проекте. На уровне РП. Доносить до Заказчика, что должна быть рабочая группа и что у сотрудников должно быть выделено время на внедрение.
И не забывать включать обучение, инструкции в скоуп работ.
Очень долго считал что имею недостаточно опыта, чтобы заниматься анализом и менеджментом задач и "хотелок" заказчиков. Но двигался в этом направлении и начал понимать, когда можно и нужно двигать свое видение, а когда послушать заказчика. Кстати очень помогает понимание MasterData management (MDM).
Из интересных случаев: после демонстрации механизмов оприходования и списания со склада заказчик заявил что это все очень сложно и он хочет просто циферки в табличке остатков напрямую менять. Достаточно немало времени понадобилось, чтобы убедить что все дополнительные процессы и операции нужны и играют роль.
Еще случай был когда заказчик попросил из старой программы скопировать механизм в новую. Т.е он реально думал что это делается простым копированием и вставкой)
Если обобщить, чем часто недоволен заказчик - это если он видит не то что хочет (что то лишнее в интерфейсе или чего-то недостает). Поэтому хотя бы на начальных этапах нужно приложить все усилия, чтобы заказчик не видел никаких лишних кнопочек, разделов, форм и декораций. Еще можно разделить заказчиков на тех, кого интересует как все работает "под капотом" и тех которым это совершенно неинтересно и любые упоминания об ограничениях их раздражают.
Кажется, что перечисленные проблемы решает ФФФ: фиксированный бюджет, фиксированный срок и изменяемый набор возможностей.
https://bureau.ru/about/fff/
Некоторые особенности заказной разработки