Сообщение администратору
Имя:
Почта:
Сообщение:
Вход на сайт
Логин:
Пароль:

Статистика
Поделиться
Поддержка  •  Дневник  •  О сайте  •  Реклама  •  Поставить баннер  •  Прислать  •  Хроника  •  Translate  •  Рекомендованное  •  Написать администратору OpenToWork Гости: 188    Участники: 1 Авторизация Авторизация   Регистрация 
Метод Научного Тыка
RULVEN
Поиск  
Blackball iMag | интернет-журнал
RSS-лента
Поделиться ссылкой:
Каталог

Статьи
Anonymous • Сб 17.09.2005 04:47

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

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


Добавлено: Вт 22.10.2013 • Sergeant
Источник: источник
Просмотров: 693
Комментарии: 0


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

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

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

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

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

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

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

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

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


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

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

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

 

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

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

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

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

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

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

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



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



Сейчас читают:
Участников (0) и гостей (0)




Комментарии: 0
Нет ни одного комментария.

Новое
OWASP: что это такое и что нужно знать веб-разработчикам Ср 12.03.2025
OWASP: что это такое и что нужно знать веб-разработчикам
Система визуализации и мониторинга. Grafana + Prometheus Вт 11.03.2025
Система визуализации и мониторинга. Grafana + Prometheus
От имени реальных HR: Squid Werewolf маскируются под рекрутеров крупных компаний Вт 11.03.2025
От имени реальных HR: Squid Werewolf маскируются под рекрутеров крупных компаний
Айтишники отправляют детей учиться на плотников и электриков. Они уверены, что ИИ уничтожит интеллектуальный труд Пн 10.03.2025
Айтишники отправляют детей учиться на плотников и электриков. Они уверены, что ИИ уничтожит интеллектуальный труд
Ретроконсоль Sega Master System II: что внутри винтажной приставки? Пн 10.03.2025
Ретроконсоль Sega Master System II: что внутри винтажной приставки?
Обиженный программист «заминировал» IT-системы энергетического гиганта Пн 10.03.2025
Обиженный программист «заминировал» IT-системы энергетического гиганта
Алгоритмы голодания: ИИ отбирает хлеб у 76 миллионов фрилансеров Пн 10.03.2025
Алгоритмы голодания: ИИ отбирает хлеб у 76 миллионов фрилансеров
Внешний аккумулятор restore: hello, world! – быстрая зарядка на пляже Вс 09.03.2025
Внешний аккумулятор restore: hello, world! – быстрая зарядка на пляже
Как компании контролируют удалённо работающих сотрудников Сб 08.03.2025
Как компании контролируют удалённо работающих сотрудников
Вайб-кодинг: программисты нашли способ зарабатывать, ничего не делая? Пт 07.03.2025
Вайб-кодинг: программисты нашли способ зарабатывать, ничего не делая?
Книги
Fundamentals of Enterprise Architecture Вт 11.03.2025
Fundamentals of Enterprise Architecture
Год: 2024
Pro .NET Memory Management, Second Edition Вт 04.03.2025
Pro .NET Memory Management, Second Edition
Год: 2024
Micro Frontends in Action Вт 18.02.2025
Micro Frontends in Action
Год: 2020
Разработано на основе BlackNight CMS
Release v.2025-03-15
© 2000–2025 Blackball
Дизайн & программирование:
О сайтеРеклама
PULS.LV Professional rating system
Visitors
Web-site performed by Sergey Drozdov
BlackballРекламаСтатистикаПоддержка
МузыкаПлейлистыКиноВидеоИгрыАудиоПрограммыСтатьиКартинкиЮморФорумДневник сайтаПрислать контентРекомендованное
Complete your gift to make an impact
Buy Me A Coffee
Если вам понравился этот сайт и вы хотите меня поддержать, вы можете купить мне кофе. Спасибо!