Об эффективности 8 лошадей — как памятка менеджерам

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

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

Искренне извиняюсь за такую нетехническую заметку, но прям «наболело» 🙂

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

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

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

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

Конечно, здесь можно задавать вопросы касающиеся метрологии и методологии — как именно измерялась мощность, как именно они были впряжены и так далее — но по сути я думаю мы все легко согласимся с этим наблюдением. Кареты запряжённые больше чем 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 человек (особенно круто если разработчиков среди них меньше половины).