Всем привет. Я работаю в заказной разработке уже больше 10-ти лет, и хочется поделиться своим опытом. Рассказать, с какими особенностями в работе я сталкиваюсь. Возможно, это найдет у вас отклик или поможет вам не совершить ошибок, или поможет быть готовым к некоторым рабочим ситуациям.
Бывает, что на этапе пресейла, могут быть даны бездумные обещания, с целью угодить Заказчику. И часто бывает, что эти обещания фактически невыполнимы.
Стратегия соглашаться на все, лишь бы войти в проект и надеяться что потом разберемся, провальная. “Потом” наступит слишком быстро, и последствия могут быть крайне неприятными. Причем разбираться скорее всего придется непосредственным участникам проекта.
На мой взгляд, о том, что возможно сделать и за какой срок, стоит говорить максимально правдиво и обдуманно. Если есть сомнения, то лучше взять паузу, обсудить со специалистами в компании. И уже после этого договариваться о функционале, который может быть реализован. А если остались спорные или непонятные моменты, их можно вынести в ограничения.
Бывает, что Заказчик настаивает на своих хотелках, даже если они нежизнеспособны. Аргументирует это тем, что он платит деньги, поэтому он прав, а мы должны делать то, что он говорит. И его хотелки могут касаться небольших интерфейсных изменений, а могут касаться и кардинальных архитектурных решений.
Мой совет - не нужно сразу бежать реализовывать. Имеет смысл провести ряд встреч для обсуждения. Донести свою позицию, подкрепить ее сравнительной таблицей вариантов, подготовить перечень возможных негативных последствий.
Но, к моему сожалению, это не всегда помогает переубедить Заказчика. И мы вынуждены делать то, что хочет Заказчик. Когда уже стало понятно что придется делать, я предлагаю потратить время на сбор всей информации в одном месте, например, в виде письма.
В письме зафиксировать свои предложения, свои рекомендации, указать на минусы предложения Заказчика. Составить перечень потенциальных последствий, а именно к чему может привести подобная реализация. Очень важно, чтобы письмо не имело надменный тон, ни в коем случае не переходить на личности и не пытаться унизить Заказчика. Этим всем вы не докажете свою правоту, а только усугубите отношения между вами и Заказчиком. Стоит написать сухо, по делу, без воды.
Однако, тут я вижу следующий важный момент. Не думайте, что потом, когда (или если когда) Заказчик будет готов признать что был не прав, у вас будет козырь в рукаве. Что вы найдете ваше письмо и произносите заветное “а я же вам говорил!” К сожалению, этого не будет. Если Заказчик признает, что его предложение было некорректным, то будет уже другая обстановка, другие вводные, да и другие люди.
Поэтому переживите ситуацию сейчас, в холодном рассудке зафиксируйте решения, примите это как факт и двигайтесь дальше.
Бывает, что Заказчику просто не нужно крутое техническое решение. И это вызывает боль у разработчиков. Разработчики хотят сделать круто и правильно. Но бывают ситуации, когда это просто не нужно.
На мой взгляд, с этим стоит просто смириться. Понять, что Заказчику может быть не нужна хорошая, правильная архитектура. Наша работа должна приносить деньги Заказчику. Поэтому может быть, что нужно просто сделать, подставить костыль. Даже если это противоречит паттернам разработки.
Для решения простых бизнес задач не нужно использовать сложные технологии. Как бы ни хотелось их применить. Всегда нужно думать о том, какую бизнес задачу мы решаем, для чего мы это делаем.
Я в своей работе часто сталкиваюсь с разработкой программного продукта не с нуля, а с внедрением коробочного решения. И уже это коробочное решение дорабатывается, или к нему пишется отдельная подсистема.
Бывает, что Заказчик высказывает следующую претензию: вы должны все знать, досконально знать, как работает решение из коробки. Или вы должны продумать значение каждого параметра, за что он отвечает, и как его применить. Что с этим делать? Здесь у меня, к сожалению, нет четкого совета. Посоветую лишь то, что делаю я. Каждый раз объяснять разницу между коробочным решением и его доработкой. Из раза в раз проговаривать, что в коробочном решении есть свои ограничения, свои проблемы, свои баги. Что Заказчик, выбирая конкретное коробочное решение, также несет ответственность за этот выбор.
Кейсов намного больше. Если тема будет интересна, могу продолжить.
Закончить хотелось бы тем, почему я продолжаю работать в заказной разработке. Я работаю в заказной разработке, потому что это позволяет мне достаточно быстро развиваться. Каждый проект уникален, имеет свои особенности, и дает мне эксклюзивный опыт. Такая работа держит меня в напряжении. Мне это нужно.
А с какими ситуациями вы сталкивались? Интересно узнать и обсудить :)
Комментарии (24)
DrinkFromTheCup
02.10.2022 18:07+1Бывает, что Заказчик настаивает на своих хотелках, даже если они нежизнеспособны. Аргументирует это тем, что он платит деньги, поэтому он прав, а мы должны делать то, что он говорит.
Умом я понимаю, что Вы пытаетесь сказать.
Но менее искушённый читатель может подумать, что Вы ведёте речь о подходе "заказчик дурак, я лучше знаю, что лучше для него".
Я бы посоветовал это как-то перефразировать.Бывает, что Заказчик высказывает следующую претензию: вы должны все знать, досконально знать, как работает решение из коробки. Или вы должны продумать значение каждого параметра, за что он отвечает, и как его применить. Что с этим делать? Здесь у меня, к сожалению, нет четкого совета.
Предпроектная аналитика тут нужна именно для этого.
Но она мертва.
saipr
02.10.2022 20:23+1принцип сначала ввязаться, потом разберемся.
Что-то напоминает. Лучше всё же разобраться и подготовиться.
un1t
02.10.2022 20:43+2На мой взгляд, о том, что возможно сделать и за какой срок, стоит говорить максимально правдиво и обдуманно. Если есть сомнения, то лучше взять паузу, обсудить со специалистами в компании. И уже после этого договариваться о функционале, который может быть реализован. А если остались спорные или непонятные моменты, их можно вынести в ограничения.
Проблема в том, что если называть реальную стоимость и сроки, то заказчик уйдет к другой фирме (которая потом также сорвет сроки и будут что-то решать со стоимостью), а то и вовсе откажется от проекта. Проблема может усугубляться тем, что премия менеджера по продажам может не зависеть от реализации проекта.
Аналогия. Возьмем двух перекупов. Первый продает убитую тачку со скрученным пробегом, не работающими тормозами и заклеенным индикатором "check engine". Второй продает тачку, за которой был хороший уход, без серьезных проблем и с небольшим пробегом. Тачки оного года выпуска, но цена у второго сильно дороже. Покупатель не понимает, почему так дорого, если точно такая же стоит сильно дешевле и покупает у первого. Да возможно второму тоже удасться когда-то найти покупателя, но устойчивый бизнес на этом не построить, поэтому продавцов первого типа полно, а вторых можно сказать не существует.
mbobka
02.10.2022 20:46+1Борьба качества с количеством. Если продажнику так хочется продать, то не проблема, если он то, что продал сверху, будет реализовывать сам за свой счёт, а не за чужой.
Куча статей написано на эту тему, что лучше отказаться от токсичного заказчика, чем пытаться любой ценой продать свои услуги/продукт.
un1t
02.10.2022 21:03+1Дело не в токсичности заказчика, а в наличии других аутсорсеров, которые толи не умеют оценивать сроки, толи держат разрабов в рабстве, толи специально их занижают, чтобы потом продать заказчику доработки. Заказчик высылает ТЗ в 10 разных компаний и смотрит на суммы. Доказать что твоя компания дает самое лучшее предложении, при том, что у восьми других дешевле довольно сложно.
По моему опыту работы аутсорсе, там это там никак не лечится. Разрабы могут избежать этой участи перейдя в продуктовые компании.
IraRum Автор
02.10.2022 21:19А наличие опыта компании не помогает показать что у вас адекватное предложение?
Отзывы других Заказчиков? Бывают, что новый Заказчик просит рекомендации от уже существующих.
IraRum Автор
02.10.2022 21:14+3Проблематику понимаю.
В нашей сфере я использую следующие способы. Если позволяет ситуация, предлагаю начать с MVP. На этапе проработки MVP мы покажем, как мы работаем. Это Заказчику позволяет наглядно увидеть, за что он платит. И после реализации поймем работаем ли дальше вместе или нет.
Детализирую скоуп работ и вместе с Заказчиком обсуждаем, какие работы можем исключить. Или, например, с целью уменьшения бюджета, часть работ Заказчик может взять на себя.
Racheengel
02.10.2022 20:50+1Бывает ещё такая ситуация: продажники продали что-либо клиенту, не уточнив или не правильно поняв требования и возможности. И вот заказ спускается в разработку, но в ранее утверждённом виде он не реализуем. Либо конкретным людям от Заказчика, которые будут работать с системой, нужно "немного не то", что было договорено "большими дядями". Вроде бы факап сейлов, но деньги заплачены, бумаги подписаны - приходится "что-то " делать.
IraRum Автор
02.10.2022 21:30+1Спасибо, за кейс. Что бы такого избежать, на этапе оценки стоит привлекать спецов. Даже если сейл уверен в своих знаниях, валидация со стороны команды не будет лишней.
Еще момент, это закладывать риски, сколько закладывать зависит от первоначальных вводных: насколько вам знаком Заказчик, насколько есть опыт в сфере, и не забывать про команду - кто это будет реализовывать. Это сложно, но возможно.
Еще хочется отдельно отметить, про определение стейкхолдеров. Есть кто платит, а есть кто будет пользоваться. "Большие дяди" о которых вы говорите, скорей всего являются спонсорами и вероятно они озвучивают бизнес требования. Стоит выявить у Заказчика тех людей, которые будут предъявлять функциональные требования.
Racheengel
03.10.2022 01:32+1Если заказчик это крупный концерн, то "достучаться" со стороны разработчика до конечных пользователей часто практически не реально. В лучшем случае это будет менеджер цеха (или нескольких). И вполне может быть, что пользователи вообще не в его подчинении, а от какой- нибудь фирмы-субсубподрядчика. И т.д. И лучшее, что может сделать этот товарищ, это собрать список пожеланий от разных смен и передать наверх по испорченному телефону. А там по цепочке. Ни о какой аналитике тут уже не идёт и речи. Если пожелания одно другому не противоречат, уже хорошо. А бывает всякое..
gleb_l
02.10.2022 23:26Все это сводится к одной фразе - кто не рискует, тот не пьёт шампанского!
Действительно, степень риска по каждой из осей суть величина, обратная определённости. Собственно, прибыль распределяется пропорционально градиенту риска по той или иной (у кого где компетенция) оси.
Будете слишком бессеребренны - в цепочку к вам встанет MITM, слишком осторожны - вас обойдёт более бесшабашный или более наглый, слишком самоуверенны - схватите куш, но половину потом отдадите врачам или в спортзале (да, у них тоже свой градиент), либо за это заплатят Ваши дети отсутствием внимания и платными репетиторами.
В целом этот закон обмануть нельзя - можно только обменяться на коротком промежутке времени тем, что менее важно вам на то, что менее важно другому.
alexhott
03.10.2022 08:37+1А еще бывает, что заказчик считает что с его стороны при смене его основного ПО не потребуется ресурсов, и один два человека с его стороны на проекте все посмотрят, а потом сразу все 300 начнут работать.
IraRum Автор
03.10.2022 10:13О да! Выделить рабочую от заказчика этот бывает тот еще квест. При чем даже если людей выделяют, то часто внедрение нового ПО идет в дополнение к основным обязанностям. Тем самым люди перегружаются, ничего не успевают, отмахиваются от внедренцев.
Об этом стоит говорить с Заказчиков при старте проекте. На уровне РП. Доносить до Заказчика, что должна быть рабочая группа и что у сотрудников должно быть выделено время на внедрение.
И не забывать включать обучение, инструкции в скоуп работ.
Grigorenkovic
03.10.2022 10:01+1Очень долго считал что имею недостаточно опыта, чтобы заниматься анализом и менеджментом задач и "хотелок" заказчиков. Но двигался в этом направлении и начал понимать, когда можно и нужно двигать свое видение, а когда послушать заказчика. Кстати очень помогает понимание MasterData management (MDM).
Из интересных случаев: после демонстрации механизмов оприходования и списания со склада заказчик заявил что это все очень сложно и он хочет просто циферки в табличке остатков напрямую менять. Достаточно немало времени понадобилось, чтобы убедить что все дополнительные процессы и операции нужны и играют роль.
Еще случай был когда заказчик попросил из старой программы скопировать механизм в новую. Т.е он реально думал что это делается простым копированием и вставкой)
Если обобщить, чем часто недоволен заказчик - это если он видит не то что хочет (что то лишнее в интерфейсе или чего-то недостает). Поэтому хотя бы на начальных этапах нужно приложить все усилия, чтобы заказчик не видел никаких лишних кнопочек, разделов, форм и декораций. Еще можно разделить заказчиков на тех, кого интересует как все работает "под капотом" и тех которым это совершенно неинтересно и любые упоминания об ограничениях их раздражают.
IraRum Автор
03.10.2022 10:21Спасибо большое! У вас крутой опыт.
Про "скопировать механизм в новую" очень знакомо. Сама афигевала от таких предложений.
И про невидимость лишней функциональности - плюсую. И по разделение команды Заказчика.
В общем и целом, согласна с вами.
ProstakovAlexey
Я работал в фирме, где был принцип снача ввязаться, потом разберемся. И она существует уже более 10 лет и с каждым годом растет. Да кто-то уходит из заказчиков, но в целом все супер. Это личный опыт, на чем основано ваше утверждение что путь провальный?
IraRum Автор
Таков мой опыт. Я наблюдала (и участвовала) в ситуациях, когда наобещаем вначале, а по итогу, не попадаем практически ни в одно обещание. И в результате все недовольны: заказчик, который ожидал другой результат, или этот результат но за другие деньги/за другое время; команда, которая работала сверхнормы, или с постоянно меняющимися требованиями и тп. Ваш пример очень интересный, после того как ввязались успешно разбирались?
ProstakovAlexey
Да, разбирались. Не идельно, часто с протоколом разногласий, перенос сроков. Но в целом лучше чем в "среднем по больнице". Хотя было 1 фиаско, но не без этого. Поэтому фирма работает и процветает сейчас. А то что все недовольны - это обычное дело. Главное что немного лучше чем работать с другими.
un1t
Только проблема вашего подхода - дать заказчику реальную оценку, означает, что фирма останется без проектов и обанкротится. Выживающие умудряются продавать заказчику доработки и допуслуги, оставляя проект прибильным.
mbobka
Потому что провальный. Деталей о фирме вы не даёте никаких, а потому могу предположить что вы фейлите все проекты и клиенты к вам не возвращаются, но ваи и не надо. У вас другая бизнес-модель. Вы просто врёте с три короба новым клиентам, которые у вас на раз, и чаржите их втридорога. Вот и всё. Вся история успеха.
Как говорится, "лох не мамонт".
Wesha
— Коллеги, — говорит Морковьева, — перед нашей организацией встала масштабная задача. Нам поступил на реализацию проект, в рамках которого нам требуется изобразить несколько красных линий. Вы готовы взвалить на себя эту задачу?
— Конечно, — говорит Недозайцев. Он директор, и всегда готов взвалить на себя проблему, которую придется нести кому-то из коллектива. Впрочем, он тут же уточняет: — Мы же это можем?