Бизнес пытается принимать технические решения

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

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

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

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

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

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

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

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

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