“Хорошие шутки” в жизни разработчиков

В пятницу подошёл ко мне Иван Ткач, чтобы обсудить предстоящую ему лекцию в ХАИ по “введению в специальность”. Встал вопрос, как показать наиболее важные проблемы нашей отрасли людям, которые ещё ничего вообще не знают… После недолгого обсуждения решили, что самой важной проблемой является несоответствие реализации ожиданиям клиента, про что я уже писал.

Как это продемонстрировать, чтобы: а) нескучно, б) задействовать самих студентов, в) не осталось и тени сомнения, что проблема имеет место быть и важна?

И тут мне пришла в голову идея – один из конкурсов в “хороших шутках” идеально отображает нашу ситуацию: там, где ведущие рисуют рисунок, одному из участников завязывают глаза и ставят перед доской, а второй, глядя на картинку, должен, называя только геометрические термины, давать указания рисующему, дабы повторить рисунок.

В общем случает выглядит это так:
ведущий –> –> описывающий –> рисующий –>

Ничего не напоминает? Ну, конечно же напоминает – вот заменяем слова ведущий, описывающий и рисующий на соответствующие роли из нашей повседневной жизни и получаем совершенно такую же картинку.
заказчик –> –> сейлс / аналитик –> разработчик –>
На том и порешили – студентам покажем конкурс: не скучно, наглядно и поучительно. А я задумался…

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

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

– привет, я аналитик в вашем проекте. Сейчас мы быстро всё выясним, и программисты это сделают в лучшем виде. Итак – что же вам нужно?
– это совсем просто: мне нужен человечек!
– ок. нет проблем, для нас это не ново. только надо выяснить некоторые минорные детали – что такое человечек?
– ну… эээ… хм… ну, типа, кружочек… там под ним идёт вертикальная линия и её пересекает горизонтальная… ага, и внизу ещё 2 диагональные из одной точки – это ноги…
– ноги? впрочем неважно. я всё понял – скоро будет, ждите.

Знакомо? Наверняка до боли…

В этом месте многие поднимут руку, чтобы сказать сакраментальное “ну так заказчик же – идиот!”. Так-то оно так, да не совсем… Если рассмотреть этот диалог со стороны заказчика, то после второго вопроса у заказчика наступает стресс (если не шок!) – он встречает человека, незнакомого с понятиями, без которых заказчик себя не мыслит. В его кругу общения наверняка нет людей, которые не знают, что такое человечек. И он лихорадочно пытается придумать, как донести до нас “очевидные” вещи. Кстати, можно только догадываться, что думает заказчик про нас в этот момент… 🙂 Вы можете поставить себя на место заказчика, попытавшись объяснить воображаемому другу понятие “оператор”, не впадая в лекции по языкам программирования.

Есть ли решение этой проблемы? Конечно есть, вот только не всем оно подходит: хотя бы аналитик (а в идеале и разработчик) должен иметь знания из предметной области – бизнеса клиента. Да, это трудно, но с другой стороны только так и получается действительно хорошее ПО. Другими словами, чтобы переводить с языка заказчика, надо этот язык знать, а лучше, чтобы переводить не надо было.

Примеры на каждом шагу. Приведу те, которые мне ближе :-):

• программу для расчётов на прочность топливных баков ракеты-носителя “Энергия” писали специалисты по прочности (одним из них был мой отец, в то время работавший в ХАИ на кафедре прочности);
• во время перестройки спрос на наукоёмкие программы подупал, зато вырос на всякую бухгалтерию. Мой отец сел писать программу всякого учёта (приход, расход, склад, зарплата, налоги и т.д.) и, чтобы написать её он выучил бухгалтерию, т.к. привык делать только то, что понимает. Выучил, кстати, настолько, что впоследствии вместо программирования рулил несколькими бизнесами без нанятого бухгалтера.
• специалисты по юзабилити создают супер удобные операционные системы, настолько удобные, что программисты не могут их не скопировать :-).

Что же делать? Ну, для обычных фрилансеров и аутсорсеров в общем ответа-то и нет, кроме как “страдать” :-). Или пытаться стать необычными.

Под необычностью я понимаю узкую специализацию – выучивайте что-то одно (ну или два), но досконально, и будет вам счастье. Да, потенциальных заказов будет поменьше (ведь вы искусственно ограничиваете поток клиентов), зато ваш продукт будет выше всяких похвал, и есть надежда, что поток будет постоянным. Отцу до сих пор звонят из ЦАГИ и КБ им.Сухого, просят написать кое-что… вот только денег не предлагают, но это уже совсем другая и грустная история.

Это относится как к маленьким игрокам, так и к большим – например, совсем не маленький DataArt смотрит как раз в нужную сторону. И это правильно.

P.S.: да, кстати, я тут подумал, что есть же и гениальные программисты, которые всё понимают, всё могут, и всё у них получается. Они не просто есть, они наверняка уже вытащили вилы, чтобы поднять на них меня в каментах… но этот постскриптум добавил мне ауру “броня +15”, так что я спокоен 🙂

-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~

UPDATE: понедельник, провели эксперимент по рисованию “проектов” и вот результат:

1. Оригинал, рисовал я;
2. Нарисовано с закрытыми глазами, в качестве описания использовались геометрические фигуры. Рисующий знал, что рисует волка;
3. Нарисовано с закрытыми глазами, в качестве описания использовались геометрические фигуры. Рисующий НЕ знал, что рисует волка;

Выводы несколько не однозначные 🙂

Иван считает, что №2 гораздо лучше (рисовал он) и это доказывает, что знать, что делаешь, нужно. Этот рисунок нарисован при минимуме инструкций с моей стороны, а именно 10. Другими словами, если разработчик знает, что делать, то при минимальном участии менеджера можно получить приемлемый результат.

Насте кажется, что №3 лучше (рисовала она), но для его рисования потребовалось больше контроля (типа “левее, стоп, теперь правее, линия вниз, стоп!” и т.д.). На этот рисунок понадобилось 33 инструкции. То есть, если микроменеджить, то всегда можно получить приемлемый результат.

Моё же мнение такое – судя по работе, у разработчиков руки из задницы, уволить! 🙂 Волков рисовать должны те, кто умеет их рисовать…