Познавательные книжки Перельмана (который Яков) очень мне нравились с детства. Один из поразивших меня тогда примеров касался сложения усилий лошадей, тянущих одну повозку.

Прошло много лет и я из проекта в проект наблюдаю ситуации (грустные), которые здорово напоминают мне эту короткую и поучительную заметку, поэтому осмелюсь её напомнить и снабдить короткими примерами.

Искренне извиняюсь за такую нетехническую заметку, но прям "наболело" :)

Краткий Пересказ

Заметка из книги "Занимательная Механика" называется "Сто Зайцев и Один Слон". Рассматривается эффективная мощность нескольких лошадей запряжённых в одну упряжку и приводится такая табличка:

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

Поясняется что "несколько лошадей, запряжённых вместе, не согласуют усилий и отчасти мешают одна другой".

Конечно, здесь можно задавать вопросы касающиеся метрологии и методологии - как именно измерялась мощность, как именно они были впряжены и так далее - но по сути я думаю мы все легко согласимся с этим наблюдением. Кареты запряжённые больше чем 4 лошадьми - явно скорее маркетинговый ход (и редко где встречаются кроме сказок).

Приводится также якобы французская поговорка "сто зайцев не делают одного слона". Я не смог найти её оригинала но звучит правдоподобно :)

Разве в IT такое бывает?

Приведу парочку абсолютно выдуманных примеров, которые, конечно, никогда не встречаются в нашей практике - и все вы согласитесь что это совершенно фантастические случаи :)

Пример №1 (разделение ответственности)

Тестировщик заводит баг "на веб-странице не отображается больше 100 сообщений об ошибках в системе". Разработчик UI получает этот баг и сообщает что проблема не на его стороне. Идут к бэкендеру, тот говорит что да, есть лимит на выдачу, дабы не положили сервер - подсказывает что можно добавить и использовать пажинацию. Юайщик говорит, мол, можно конечно и пажинацию, но пусть мне дизайнер скажет где разместить кнопку переключения страниц. Дизайнер говорит что надо бы сходить к аналитику и уточнить, надо ли делать с кнопкой или с помощью "бесконечной прокрутки". Аналитик уходит в глубокую задумчивость, проводит совещание, потом другое - наконец что-то решили - и цепочка разворачивается в обратном порядке. Добавляют пажинацию на бэкенде, добавляют на фронтенде, попробовали, всё вроде хорошо. И двух недель не заняло. Всё это время прибегал менеджер и глядя в джиру напоминал "у вас там бага, я не знаю что это за бага, но её надо фиксить в текущей версии". Заходил также и скрам-мастер, спрашивая по нескольку раз, успевают ли эту багу в спринте и сколько стори-пойнтов ей назначить.

Правда архитект по результату язвительно замечает что если ошибок будет хотя бы больше 10, то просматривать всю портянку на юае никто не будет - система явно неработоспособна, заказчик пришлёт лог и велит исправлять.

Пример №2 (масштабирование команды)

Жил да был проект, некий коммуникационный сервер. Он состоял из набора модулей и даже через год-другой - уже из отдельных сервисов - и работало над ним человек 20 к тому моменту. В какой-то момент поняли что с небольшими доделками и изменениями его можно использовать в качестве конфигурационного сервера. Выделили 3 человек которые стали писать "сбоку-припёку" для опционального использования этого детища в новом качестве. Можно сказать, это похоже на кастомизацию. Но уж очень неудобно двум командам работать над одной кодовой базой - кастомизация всегда много проблем влечет.

И решено на уровне менеджмента разделить проекты - то есть, выделить "конфигурационный" сервер в отдельную репу и независимую команду. Но не смогут ведь 3 человека работать над этой штукой целиком! Надо команду усилить. А насколько усилить - всё понятно - если над исходным проектом 20 человек работают, то и после разделения в каждой "половине" должно быть по 20 человек. И поставлена задача HR-отделу нанять 20 душ (из них 15 разработчиков, 3 тестировщика и 2 аналитика).

А до того пока удастся набрать хотя бы десяток разделять проект нельзя - работать над ним будет некому. Вот как наберем - как набросимся - и тут конечно всё понесется. Правда терзает смутное сомнение что нужно будет потратить усилия на то чтобы выпилить из проекта все ненужные архаизмы (от коммуникационного сервера в наследство доставшиеся) - но понятно что новички этим заняться не смогут, по незнанию проекта. Ну да поглядим - главное, сперва ввязаться в драку.

Пример №3 (то же что №1 но между отделами)

В команду требуется нанять ещё 2 человек. Соответствующие заявки через линейного менеджера и менеджера департамента оформлены в адрес руководства HR-отдела, спущены нижестоящим рекрутёрам, а от них "сорсерам-стажёрам". Время идёт, а люди как-то все не появляются. Хотя рекрутёры и сорсеры вроде бы работают старательно и даже иногда какие-то странные типы приходят на собеседование.

Наконец месяца 3 спустя в команду добавляется один (пока) человек. Втягивается в работу, то да се - и как-то при нём упоминают про то что ещё одного пока ищут. Он с удивлением говорит "Надо же - а я на ваши вакансии раз 5 откликался - сразу получал отлуп автоматом, мол вы нам пока не нужны но спасибо за интерес к вакансии. Честно говоря думал сюда вообще нет шансов попасть".

Заключение

Что я хотел сказать? Не скажу :) За меня сказал Перельман. И ещё Крылов (его часто называют "дедушкой Крыловым" - но басни-то он свои в молодости писал) - напомним это картинкой.

С другой стороны, как же быть если нам нужно увезти поклажу многократно превосходящую возможности одной лошади?

Мы все интуитивно понимаем что эта задача не является нерешаемой. Пару вариантов представим опять же в картинках.

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

И главное - что проблемы есть а не вот это "встанем в круг и повторяем мантру: мы лучшая компания у нас все хорошо".

Хотя повторюсь, упомянутые примеры я конечно взял из головы и на самом деле ничего подобного в наших великих и могучих IT-шных компаниях не бывает :) Это всё про какие-то другие компании.

P.S. Особенно удивляешься когда на гитхабе обнаруживаешь какой-нибудь популярный проект (ну, допустим, тоже коммуникационный сервер) - оказывается что его пилит в одно жало какой-то энтузиаст плюс по чуть-чуть добавляют случайные контрибуторы. А у нас-то код сравнимого размера обслуживается командой из 30 человек (особенно круто если разработчиков среди них меньше половины).