Спрятать панель проектов Показать панель проектов
Donation Пожертвование  |  Дневник  |  Гостевая  |  О сайте  |  Реклама  |  .mobile
Новый сервер, 500 € заслать денег PayPal
0 € (0%)
Поиск  
iMag | интернет-журнал

Разделы

Реклама
Начало » Разработка ПО » Как я был идеальным заказчиком

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


 

Добавлено: 22.10.2013 (Sergeant)
Источник: http://habrahabr.ru/post/198472/

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

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

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

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

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

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

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

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

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


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

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

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

 

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

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

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

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

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

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

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


 
Мне нравится
?
Мне не нравится


Писать комментарии могут только авторизованные пользователи.


Комментарии (0)
Нет ни одного комментария.
Поделиться ссылкой:
Новое
Сб 01.04.2017 – Гороскоп для разработчиков
Construct 2 Game Development by ExampleПн 16.01.2017 – Construct 2 Game Development by Example
Год: 2014
Design Patterns in C#Пн 09.01.2017 – Design Patterns in C#
Год: 2012
Язык программирования C# 5.0 и платформа .NET 4.5Пн 02.01.2017 – Язык программирования C# 5.0 и платформа .NET 4.5
Год: 2013
Patterns Principles and Practices of Domain-Driven DesignПн 26.12.2016 – Patterns Principles and Practices of Domain-Driven Design
Год: 2015
Приёмы объектно-ориентированного проектирования. Паттерны проектированияПн 19.12.2016 – Приёмы объектно-ориентированного проектирования. Паттерны проектирования
Год: 2001
The C# Player's Guide, 2nd EditionПн 12.12.2016 – The C# Player's Guide, 2nd Edition
Год: 2015
Web UI Design PatternsПн 05.12.2016 – Web UI Design Patterns
Год: 2014
Xamarin Mobile Application DevelopmentПн 28.11.2016 – Xamarin Mobile Application Development
Год: 2015
Стрессоустойчивость. Как сохранять спокойствие и высокую эффективность в любых ситуацияхВт 22.11.2016 – Стрессоустойчивость. Как сохранять спокойствие и высокую эффективность в любых ситуациях
Год: 2014

Реклама
Разработано на основе BlackNight CMS
Release v.2016-11-22
© 2000–2017 Blackball
Дизайн & программирование:
Sergeant Центр Связи с Админом Skeleton
О сайтеРеклама
Яндекс.Метрика
Web-site performed by Sergey Drozdov