Некоторые особенности заказной разработки
Всем привет. Я работаю в заказной разработке уже больше 10ти лет, и хочется поделиться своим опытом. Рассказать, с какими особенностями в работе я сталкиваюсь. Возможно, это найдет у вас отклик или поможет вам не совершить ошибок, или поможет быть готовым к некоторым рабочим ситуациям.
Бывает, что на этапе пресейла, могут быть даны бездумные обещания, с целью угодить Заказчику. И часто бывает, что эти обещания фактически невыполнимы.
Стратегия соглашаться на все, лишь бы войти в проект и надеяться что потом разберемся, провальная. «Потом» наступит слишком быстро, и последствия могут быть крайне неприятными. Причем разбираться скорее всего придется непосредственным участникам проекта.
На мой взгляд, о том, что возможно сделать и за какой срок, стоит говорить максимально правдиво и обдуманно. Если есть сомнения, то лучше взять паузу, обсудить со специалистами в компании. И уже после этого договариваться о функционале, который может быть реализован. А если остались спорные или непонятные моменты, их можно вынести в ограничения.
Бывает, что Заказчик настаивает на своих хотелках, даже если они нежизнеспособны. Аргументирует это тем, что он платит деньги, поэтому он прав, а мы должны делать то, что он говорит. И его хотелки могут касаться небольших интерфейсных изменений, а могут касаться и кардинальных архитектурных решений.
Мой совет — не нужно сразу бежать реализовывать. Имеет смысл провести ряд встреч для обсуждения. Донести свою позицию, подкрепить ее сравнительной таблицей вариантов, подготовить перечень возможных негативных последствий.
Но, к моему сожалению, это не всегда помогает переубедить Заказчика. И мы вынуждены делать то, что хочет Заказчик. Когда уже стало понятно что придется делать, я предлагаю потратить время на сбор всей информации в одном месте, например, в виде письма.
В письме зафиксировать свои предложения, свои рекомендации, указать на минусы предложения Заказчика. Составить перечень потенциальных последствий, а именно к чему может привести подобная реализация. Очень важно, чтобы письмо не имело надменный тон, ни в коем случае не переходить на личности и не пытаться унизить Заказчика. Этим всем вы не докажете свою правоту, а только усугубите отношения между вами и Заказчиком. Стоит написать сухо, по делу, без воды.
Однако, тут я вижу следующий важный момент. Не думайте, что потом, когда (или если когда) Заказчик будет готов признать что был не прав, у вас будет козырь в рукаве. Что вы найдете ваше письмо и произносите заветное «а я же вам говорил!» К сожалению, этого не будет. Если Заказчик признает, что его предложение было некорректным, то будет уже другая обстановка, другие вводные, да и другие люди.
Поэтому переживите ситуацию сейчас, в холодном рассудке зафиксируйте решения, примите это как факт и двигайтесь дальше.
Бывает, что Заказчику просто не нужно крутое техническое решение. И это вызывает боль у разработчиков. Разработчики хотят сделать круто и правильно. Но бывают ситуации, когда это просто не нужно.
На мой взгляд, с этим стоит просто смириться. Понять, что Заказчику может быть не нужна хорошая, правильная архитектура. Наша работа должна приносить деньги Заказчику. Поэтому может быть, что нужно просто сделать, подставить костыль. Даже если это противоречит паттернам разработки.
Для решения простых бизнес задач не нужно использовать сложные технологии. Как бы ни хотелось их применить. Всегда нужно думать о том, какую бизнес задачу мы решаем, для чего мы это делаем.
Я в своей работе часто сталкиваюсь с разработкой программного продукта не с нуля, а с внедрением коробочного решения. И уже это коробочное решение дорабатывается, или к нему пишется отдельная подсистема.
Бывает, что Заказчик высказывает следующую претензию: вы должны все знать, досконально знать, как работает решение из коробки. Или вы должны продумать значение каждого параметра, за что он отвечает, и как его применить. Что с этим делать? Здесь у меня, к сожалению, нет четкого совета. Посоветую лишь то, что делаю я. Каждый раз объяснять разницу между коробочным решением и его доработкой. Из раза в раз проговаривать, что в коробочном решении есть свои ограничения, свои проблемы, свои баги. Что Заказчик, выбирая конкретное коробочное решение, также несет ответственность за этот выбор.
Кейсов намного больше. Если тема будет интересна, могу продолжить.
Закончить хотелось бы тем, почему я продолжаю работать в заказной разработке. Я работаю в заказной разработке, потому что это позволяет мне достаточно быстро развиваться. Каждый проект уникален, имеет свои особенности, и дает мне эксклюзивный опыт. Такая работа держит меня в напряжении. Мне это нужно.
А с какими ситуациями вы сталкивались? Интересно узнать и обсудить :)
