вторник, 6 мая 2014 г.

Не слишком серьёзные размышления о нашей тяге к разработке платформ

Данное сообщение изначально было размещено мною на сайте RSDN в разделе "философия программирования". 

"Что делают программисты, когда собираются вместе? Правильно — пишут фреймворк"
(с) Волков, Танки Онлайн, неточная цитата.
Я неоднократно видел одну и ту же ситуацию — вместо разработки решения для конкретной бизнес-задачи команда начинает пилить обобщенное техническое решение, платформу или каркас. Обычно это подается под соусом снижения затрат на будущие разработки, дескать, сейчас "наработаем технологию" (или даже "наработаем архитектуру"), а потом на ее основе за три дня слепим конечный продукт. А потом и еще десяток, если надо будет.

Я лично участвовал в пяти проектах, которые развивались по этой схеме. Вот результаты:
1. Три полностью провалились (т.е. были отменены после того, как сожрали изрядно денег и не дали никакого полезного результата). 
2. Один еле вытащили до состояния shippable-продукта (т.е. все обещанные плюшки от разработки платформы пошли лесом, оставив переусложненную и нестабильную кодовую базу, в которую были зарыты крупные деньги).
3. Один, участником которого я являюсь сейчас, так же борется за жизнь, но есть сильный риск того, что он повторит первый или второй сценарий.
Про случаи, о которых я знаю по наслышке, я рассказывать не буду, но их ещё больше.

"Тенденция, однако" (с)

Моя скромная гипотеза, объясняющая этот феномен, состоит в том, что типичным технарям просто психологически комфортнее делать технологию, а не конечный продукт, обладающий business-value. Разработчики — эгоцентристы, им некомфортно влезать в шкуру пользователя, учиться смотреть на мир его глазами, понимать его проблемы, получать от него негативный фидбек. Им гораздо проще и интересное заниматься технологией ради нее самой, потому что там не надо выходить из своей зоны комфорта. Технология делается не для пользователей, а для самих себя (или же других разработчиков), так что можно обойтись привычной картиной мира критериями оценки результата, да и общаться с потребителем проще. 

Поэтому, они стараются максимально оттянуть тот момент, когда им потребуется решать реальные проблемы клиента. Но, делать что-то надо, вот и появляется такая уловка — мол, клиентскими проблемами мы займемся завтра, а сейчас мы подготовим для этого солидную техническую базу. Истинная цель этой стратегии — оправдать в своих глазах и в глазах руководства замыкание в своей зоне комфорта, изолированной от реальных целей проекта, продиктованных бизнесом. Получить возможность избежать неприятных коммуникаций о бизнес-проблеме и принятия решений, основанных не на привычных критериях (техническое совершенство), а на чуждых среднему разработчику критериях бизнеса. То же самое, в миниатюре, можно видеть, когда при обсуждении трудного и неоднозначного вопроса проектирования, команда дружно и с улыбкой решает "заложить гибкость", вместо того, чтобы разобраться в проблеме и выбрать оптимальный вариант.

Я не говорю, что фреймворки и платформы — это зло и их не надо разрабатывать в принципе. Есть ситуации, когда такой подход к разработке полностью оправдан. Но ни в одном из упомянутых мною пяти проектов не было сделано никакого серьёзного анализа для выбора стратегии разработки. Все оправдания для выбранного пути сводились к чисто устному "бла-бла-бла, снижение затртат, бла-бла-бла". Никто не посчитал, насколько затраты снизятся, никто не посчитал ни одной цифры, не провёл анализ рисков такого подхода и т.п. 

Зло, о котором я говорю — это именно такой подход, а не результат.

2 комментария:

  1. Еще один момент: делать платформу/фрэймворк имея одного клиента или не имея их вообще - гиблое дело, потому что разработчики просто не знают а что же в их системе есть такое общее что можно переиспользовать для других (будущих) клиентов. Как говорил Боб Мартин, платформу можно написать только если одновременно в разработке находится несколько проектов; иначе это пустая трата ресурсов.

    ОтветитьУдалить