Это поучительный рассказ о том, как после многих лет работы на стороне исполнителя мне довелось побывать по ту сторону баррикад и заказывать разработку на стороне. Это рассказ о том, почему для разработчика нет ничего страшнее идеального заказчика.
Как я уже говорил, я много лет занимался работой с заказчиками в софтверной компании. Так вот – мне приходилось работать с разными заказчиками – с отечественными и с зарубежными, с международными корпорациями и со стартаперами-одиночками.
Я видел всё, что только бывает. Я видел пафосных московских менеджеров, к которым надо было приезжать раз в неделю, потому что говорить по телефону – это западло, и видел простого американского парня, который взял и прилетел на месяц к нам в Сибирь под новый год, чтобы лично объяснить разработчикам, чего он хочет.
Я работал со странными людьми, которые составляли ТЗ в половину странички, с неадекватами, которые переписывали спецификацию раз в неделю, с мудаками, которые считали себя рабовладельцами. Мы делали фичи, которые не поддерживало железо, разрабатывали приложения под ось, которая еще не вышла и адаптировали под ретину дизайн, нарисованный ребенком в редакторе Paint. Я работал с психами, которые грозились миллионными штрафами за день просрочки промежуточного релиза.
Я имел дело с перекупщиками, которые понятия не имели, чего хочет конечный покупатель, я встречал неадекватов, которые понимали как надо только после того, как мы сделаем, как просят.
Я работал с заказчиками, которые «я вообще-то тоже программист» и пытались учить нас делать свою работу. Я знаю, что такое переделывать всё с нуля по три раза за проект.
Однажды у меня был заказчик, соскочивший с проекта, потому что у него сгорел офис со всем железом и данными. Однажды нам пришлось за 200 баксов делать клон, хотя нет – продвинутый клон родного яблочного приложения в то время, когда они еще не открыли сторонним разработчикам доступ ко многим своим фичам.
В общем, я работал со всеми видами невозможного и невыполнимого. Я понимаю, каково делать то, не знаю, что, так, чтобы еще вчера было готово.
Так вот — каждый раз, когда я встречал очередного «чего там работать, сделайте как в фейсбуке» клиента, я давал себе слово, даже нет – я клялся могилами предков, что вот уж я бы на его месте так себя не вел. Я бы на его месте работал так, что разработчик еще и приплачивал бы за удовольствие иметь со мной дело. Уж я бы на его месте мог бы стать просто самым лучшим заказчиком. И однажды я им стал.
Как и любая софтверная компания, однажды мы захотели сделать «свой продукт». И как в любой софтверной компании у нас не было свободных разработчиков. Поэтому было принято героическое решение применить модный аутсорсинг. Ну а я уже стал проектировщиком и проджект-менеджером.
Немного поторговавшись, мы нашли исполнителя, заключили настоящий договор, и я официально стал заказчиком. Как и клялся, я стал самым лучшим из всех заказчиков.
В общем, во всех отношениях я старался быть таким заказчиком, о котором сам всегда мечтал. Но со временем я стал замечать, что мой подрядчик не разделяет моего восторга. Мне начало казаться, что для него я просто ночной кошмар. Вероятно, он считал меня своим худшим клиентом и проклинал тот день, когда прочитал моё объявление.
Прошло немало времени, прежде чем я понял, почему со мной так тяжело работать. И это понимание полностью изменило мое представление об отношениях заказчика и исполнителя в сфере ИТ.
Во-первых, я слишком хорошо ориентировался в требованиях. Соответственно меня было тяжело убедить в том, что какие-то детали нуждаются в дополнительных пояснениях или примерах и получить таким образом дополнительное время. Любые пояснения и примеры приводились сразу же.
Во-вторых, я был конечным заказчиком – именно заказчиком, даже не представителем. Поэтому со мной было невозможно договориться не заметить каких-то багов или подписать акты под честное слово всё поправить потом.
Ну и самое главное. Я слишком хорошо представлял себе результат, который хотел получить. Это самое парадоксальное, потому что обычно проблема как раз в обратном. Дело в том, что в моём случае всё проектирование было на нашей стороне. Подрядчик получал готовые и свёрстанные страницы с подробными пояснениями в стиле «если нажать сюда, то появляется вот такой попап».
Я думаю, любой согласится, что чем абстрактнее требования, тем проще работать. А мои требования были настолько конкретизированы, что разработчик полностью лишался пространства для манёвра. И если он не мог что-то реализовать (особенно на фронт-енде), то у него просто не было возможности сделать по-другому – сделать так, как умеет. В результате любую проблему приходилось решать самым сложным способом, потому что обходной путь всегда был отрезан.
Так и получилось, что моё самое главное достоинство обернулось самым главным недостатком. Какая в этом мораль? Такая, что нельзя разделять проектирование и разработку. Идеальный заказчик не должен в деталях прописывать поведение каждого контрола. Идеальный заказчик должен описать задачи, которые приложение должно решать и условия, в которых оно должно это делать. Всё остальное разработчик должен делать сам – только тогда появляется шанс, что он сможет воплотить свои собственные идеи. Потому что с чужими идеями всё гораздо сложнее.
Как я уже говорил, я много лет занимался работой с заказчиками в софтверной компании. Так вот – мне приходилось работать с разными заказчиками – с отечественными и с зарубежными, с международными корпорациями и со стартаперами-одиночками.
Я видел всё, что только бывает. Я видел пафосных московских менеджеров, к которым надо было приезжать раз в неделю, потому что говорить по телефону – это западло, и видел простого американского парня, который взял и прилетел на месяц к нам в Сибирь под новый год, чтобы лично объяснить разработчикам, чего он хочет.
Я работал со странными людьми, которые составляли ТЗ в половину странички, с неадекватами, которые переписывали спецификацию раз в неделю, с мудаками, которые считали себя рабовладельцами. Мы делали фичи, которые не поддерживало железо, разрабатывали приложения под ось, которая еще не вышла и адаптировали под ретину дизайн, нарисованный ребенком в редакторе Paint. Я работал с психами, которые грозились миллионными штрафами за день просрочки промежуточного релиза.
Я имел дело с перекупщиками, которые понятия не имели, чего хочет конечный покупатель, я встречал неадекватов, которые понимали как надо только после того, как мы сделаем, как просят.
Я работал с заказчиками, которые «я вообще-то тоже программист» и пытались учить нас делать свою работу. Я знаю, что такое переделывать всё с нуля по три раза за проект.
Однажды у меня был заказчик, соскочивший с проекта, потому что у него сгорел офис со всем железом и данными. Однажды нам пришлось за 200 баксов делать клон, хотя нет – продвинутый клон родного яблочного приложения в то время, когда они еще не открыли сторонним разработчикам доступ ко многим своим фичам.
В общем, я работал со всеми видами невозможного и невыполнимого. Я понимаю, каково делать то, не знаю, что, так, чтобы еще вчера было готово.
Так вот — каждый раз, когда я встречал очередного «чего там работать, сделайте как в фейсбуке» клиента, я давал себе слово, даже нет – я клялся могилами предков, что вот уж я бы на его месте так себя не вел. Я бы на его месте работал так, что разработчик еще и приплачивал бы за удовольствие иметь со мной дело. Уж я бы на его месте мог бы стать просто самым лучшим заказчиком. И однажды я им стал.
Как и любая софтверная компания, однажды мы захотели сделать «свой продукт». И как в любой софтверной компании у нас не было свободных разработчиков. Поэтому было принято героическое решение применить модный аутсорсинг. Ну а я уже стал проектировщиком и проджект-менеджером.
Немного поторговавшись, мы нашли исполнителя, заключили настоящий договор, и я официально стал заказчиком. Как и клялся, я стал самым лучшим из всех заказчиков.
- Я платил нормальные деньги. Такие, за которые мы сами стали бы работать.
- У меня был настоящий бэклог, содержащий четкие, конкретные и, самое главное, непротиворечивые требования.
- Я не менял требования в течение проекта, не вмешивался в спринты и не просил что-то переделать потому что плохо подумал.
- Исполнитель мог сам выбирать технологии разработки, архитектуру и писать код по своим правилам.
- У нас не было испорченного телефона, я был основным контактным лицом и я же формировал требования.
- Никакого языкового барьера и проблем с доступностью для общения.
- У меня была внятная спека — каждый экран был отрисован профессиональным UX-дизайнером, поведение каждой кнопочки было расписано.
- Я сам проводил приемочные тесты.
- Я знал реалии разработки, понимал что у всех бывают баги и задержки.
- Я не был программистом, который знает как надо.
В общем, во всех отношениях я старался быть таким заказчиком, о котором сам всегда мечтал. Но со временем я стал замечать, что мой подрядчик не разделяет моего восторга. Мне начало казаться, что для него я просто ночной кошмар. Вероятно, он считал меня своим худшим клиентом и проклинал тот день, когда прочитал моё объявление.
Прошло немало времени, прежде чем я понял, почему со мной так тяжело работать. И это понимание полностью изменило мое представление об отношениях заказчика и исполнителя в сфере ИТ.
Во-первых, я слишком хорошо ориентировался в требованиях. Соответственно меня было тяжело убедить в том, что какие-то детали нуждаются в дополнительных пояснениях или примерах и получить таким образом дополнительное время. Любые пояснения и примеры приводились сразу же.
Во-вторых, я был конечным заказчиком – именно заказчиком, даже не представителем. Поэтому со мной было невозможно договориться не заметить каких-то багов или подписать акты под честное слово всё поправить потом.
Ну и самое главное. Я слишком хорошо представлял себе результат, который хотел получить. Это самое парадоксальное, потому что обычно проблема как раз в обратном. Дело в том, что в моём случае всё проектирование было на нашей стороне. Подрядчик получал готовые и свёрстанные страницы с подробными пояснениями в стиле «если нажать сюда, то появляется вот такой попап».
Я думаю, любой согласится, что чем абстрактнее требования, тем проще работать. А мои требования были настолько конкретизированы, что разработчик полностью лишался пространства для манёвра. И если он не мог что-то реализовать (особенно на фронт-енде), то у него просто не было возможности сделать по-другому – сделать так, как умеет. В результате любую проблему приходилось решать самым сложным способом, потому что обходной путь всегда был отрезан.
Так и получилось, что моё самое главное достоинство обернулось самым главным недостатком. Какая в этом мораль? Такая, что нельзя разделять проектирование и разработку. Идеальный заказчик не должен в деталях прописывать поведение каждого контрола. Идеальный заказчик должен описать задачи, которые приложение должно решать и условия, в которых оно должно это делать. Всё остальное разработчик должен делать сам – только тогда появляется шанс, что он сможет воплотить свои собственные идеи. Потому что с чужими идеями всё гораздо сложнее.
