Как я был идеальным заказчиком

от автора

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

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

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

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

Я имел дело с перекупщиками, которые понятия не имели, чего хочет конечный покупатель, я встречал неадекватов, которые понимали как надо только после того, как мы сделаем, как просят.

Я работал с заказчиками, которые «я вообще-то тоже программист» и пытались учить нас делать свою работу. Я знаю, что такое переделывать всё с нуля по три раза за проект.

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

Вобщем, я работал со всеми видами невозможного и невыполнимого. Я понимаю, каково делать то, не знаю, что, так, чтобы еще вчера было готово.

Так вот — каждый раз, когда я встречал очередного «чего там работать, сделайте как в фейсбуке» клиента, я давал себе слово, даже нет – я клялся могилами предков, что вот уж я бы на его месте так себя не вел. Я бы на его месте работал так, что разработчик еще и приплачивал бы за удовольствие иметь со мной дело. Уж я бы на его месте мог бы стать просто самым лучшим заказчиком. И однажды я им стал.


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

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

  1. Я платил нормальные деньги. Такие, за которые мы сами стали бы работать.
  2. У меня был настоящий бэклог, содержащий четкие, коткретные и, самое главное, непротиворечивые требования.
  3. Я не менял требования в течение проекта, не вмешивался в спринты и не просил что-то переделать потому что плохо подумал.
  4. Исполнитель мог сам выбирать технологии разработки, архитектуру и писать код по своим правилам.
  5. У нас не было испорченного телефона, я был основным контактным лицом и я же формировал требования.
  6. Никакого языкового барьера и проблем с доступностью для общения.
  7. У меня была внятная спека — каждый экран был отрисован профессиональным UX-дизайнером, поведение каждой кнопочки было расписано.
  8. Я сам проводил приемочные тесты.
  9. Я знал реалии разработки, понимал что у всех бывают баги и задержки.
  10. Я не был программистом, который знает как надо.

Вобщем, во всех отношениях я старался быть таким заказчиком, о котором сам всегда мечтал. Но со временем я стал замечать, что мой подрядчик не разделяет моего восторга. Мне начало казаться, что для него я просто ночной кошмар. Вероятно, он считал меня своим худшим клиентом и проклинал тот день, когда прочитал моё объявление.

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

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

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

Ну и самое главное. Я слишком хорошо представлял себе результат, который хотел получить. Это самое парадоксальное, потому что обычно проблема как раз в обратном. Дело в том, что в моём случае всё проектирование было на нашей стороне. Подрядчик получал готовые и свёрстанные страницы с подробными пояснениями в стиле «если нажать сюда, то появляется вот такой попап».

Я думаю, любой согласится, что чем абстрактнее требования, тем проще работать. А мои требования были настолько конкретизированы, что разработчик полностью лишался пространства для манёвра. И если он не мог что-то реализовать (особенно на фронт-енде), то у него просто не было возможности сделать по-другому – сделать так, как умеет. В результате любую проблему приходилось решать самым сложным способом, потому что обходной путь всегда был отрезан.

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

ссылка на оригинал статьи http://habrahabr.ru/post/198472/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *