Об эффективности 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-шных компаниях не бывает :) Это всё про какие-то другие компании.
