Среди всех этих историй, безусловно, есть иные. А есть те, кто мне не пишут, а просто делают. Свой «Магнит» или СУ-155. Думаю, таких немало. А вот со всеми остальными надо что-то делать. Учить, видимо. И в школах явно не помешает курс по предпринимательству. И во всех вузовских программах. Чтобы быстро вырастить если не культуру, то хотя бы понимание отличия бизнеса и хобби. Так думаю.

#проектирование #ожиданиязаказчика

#формулированиецелей

Когда я был программистом, в проектировании ПО было принято два подхода: снизу вверх и сверху вниз. Суть простая: сверху вниз мы от более абстрактных задач идем к менее абстрактным, анализируя общее и декомпозируя на частное, доходя до руды – функций. В случае снизу вверх мы синтезируем, идем от частного к общему, в современных терминах – проверяем гипотезы. Например: мы пишем систему управления заводом и начинаем разработку с драйвера обмена данными с конкретным оборудованием. В зависимости от того, как его удастся реализовать, меняется структура системы. Кстати, пример из практики.

Так вот, были сторонники того и другого подхода. О, сколько замечательных споров было на этот счет! А сколько прочитано книг! Это как эпическое сражение water flow и agile, почти как гендерные войны. И все никак не могли прийти к консенсусу: а что же лучше? Вот, скажем, система управления зданием. Сели, описали хотелки заказчика, исходя из них выбрали железо и написали (дописали) софт. Сдали. Заказчик счастлив? Нет, он как бы в целом доволен, но не очень понимает, для чего нужно все это в целом. То есть каждую функцию системы понимает, а как и для чего ему все это вместе – нет. И, главное, отчего эти функции так взаимоувязаны. И отчего они такие именно у него. А все почему? Потому что на входе в проект он не был вовлечен в формулирование целей. Вернее, этого формулирования и не было. Шел синтез «в космосе».

Или обратная ситуация. Делаем систему управления предприятием: продажа, производство, сервис, экономика и легонький такой управленческий учет. Так сказать, full custom SAP Light на C++. Идем от исследований. Все как полагается, модель as is, модель to be, туча use cases, от UML рябит в глазах. Кстати, вы видели когда-нибудь «красного директора» оборонного предприятия, который на совещании с топ-менеджментом обсуждает business use case системы? А вот я видел: душераздирающее, доложу вам, зрелище. И вот в какой-то момент этого анализа заказчик становится совсем несчастным. Нет, все хорошо, все правильно, мы тщательно и с криками выявляем его потребности и ожидания. Его, прости господи, key needs. Но он пощупать уже что-то хочет. Хотя бы документооборот. Хотя бы между ним и его помощником. А не этот анализ «в космосе».

Обратите внимание: и в первом, и во втором случае заказчик несчастлив. Да, вы можете сказать, что команды были непрофессиональны. Да, вы можете сказать, что заказчик был «не созревший». Думаю, все так и было. Но лично в моей практике эта ситуация повторялась раз за разом. И когда речь шла о программных проектах, и организационных. Всегда шел рассинхрон между желанием сделать «все по уму» и потребностью «здесь и сейчас». И суровейшие кризисы в проектах были обусловлены этим рассинхроном. Проектная команда и заказчик смотрели друг на друга и друг от друга раздражались. Потому что если у проектной команды в голове методология и принцип do right right things, то у заказчика – его бабки и потраченное время. Согласитесь, есть почва для конфликта.

Я это к чему? Можно проектировать как угодно и нужно выбирать способ в зависимости от контекста и темперамента заказчика. Важно понимать, что и тот и другой метод подразумевает, что в голове или на бумаге есть big picture, образ результата программы или системы. И что это образ должен предельно одинаково отображаться в голове и на бумагах у заказчика и исполнителя. И что есть работающие методы синхронизации этого образа. Потому что он имеет обыкновение «расползаться» во времени. Ну так как аппетит растет во время еды, и «за время пути собачка смогла подрасти».