Посторонним В.

Нашел подборку фотографий мобилкой, еще с 2007 года из замечательной компании “Столица-Медикл”. На фотографиях мой тогдашний босс и коллега. Все описанное на картинках сплошной вымысел, на самом деле мужики очень профессиональные и дело свое знают лучше всех.

Чем больше команда, тем больше времени надо на коммуникации. Тем дольше информация расползается по команде. Рассмотрим обычную ситуацию: компания из 2 000 сотрудников, 10 топ-менеджеров, под каждым топом 10 менеджеров среднего звена, под каждым менеджером среднего звена еще по 3 руководителя группы. Допустим, на совете топ-менеджеров приняли какое-то решение, которое касается деятельности каждого сотрудника. Решение непростое, большое, емейлом и не описать вот так. И тогда каждый топ-менеджер собирает своих сотрудников на совещание. То есть нужно провести еще 10 совещаний. Отчетные совещания проходят раз в две недели, да и если созывать внеплановое совещание, все равно раньше, чем через 2 недели, всех собрать толком и не получится. После этого каждый менеджер среднего звена на летучке отдела все сообщит, а это будет еще через неделю. В промежутках между совещаниями на разных уровнях идет активная переписка с уточнениями и вопросами касательно принятого решения.

И что же мы видим: более-менее объемная информация распространяется от руководства до младших сотрудников не менее чем за 3 недели. И это в относительно небольшой компании. Сокращение сотрудников компании до 200 человек (в 10 раз) уменьшит срок прохождения только на 1 неделю, то есть время доставки информации зависит от количества уровней иерархии. Что же делать?

Руководство никому не доверяет принятие решений
В этом случае нужно основную часть коммуникаций перенести в онлайн, например, в интранет-систему. Это позволит не отвечать на один и тот же вопрос дважды, да и не будет необходимости собирать кучу народа на совещания. Также это поможет избежать ошибок коммуникации (про которые я писал ранее). Подобным образом поступают, например, компании “большой четверки”.

Руководство свободно делегирует принятие решений
В этом случае нужно создавать небольшие автономные группы, которые должны быть максимально независимыми от деятельности остальных групп. И каждой группе выдавать свое направление для работы, предоставляя ей самой уже решать, как именно развивать это направление и выходить на нужные показатели. За счет небольшого размера группы ошибок коммуникации не будет. Таким образом действуют, например, компании Virgin и Gore.

Оба пути имеют право на существование, так что тут решать только вам, как поступить.

Не бывает сложных проблем, задач, решений или систем. Но, “просто” не значит “легко”. Если вы проектируете сложную систему и сразу закладываете сложности, лучше бросайте это дело и займитесь чем-нибудь другим, все равно такая система обречена на провал. Все в нашем мире устроено просто и единственная сложность, которая есть, это многообразие вариантов и комбинаций простых вещей. Мастерство тем выше, чем меньше простых составляющих нужно для получения результата. Особенно это заметно в больших системах, где сходу нельзя определить минимальное необходимое и достаточное количество простых элементов. Касательно технологических проектов и стартапов это хорошо видно: те, которые начинали с гаража/одного сервера, сейчас имеют преимущество перед теми, которые начинали с какой-то сложной схемы.

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

Сложность системы можно определять по временной шкале: сколько времени нужно инженеру, чтобы разобраться, как работает система. Если срок приближается к году или даже больше, что-то явно не так. Либо же вы разрабатываете военный/космический проект, начатый еще 25 лет назад. Выгода определения сложности в человекоднях очевидна: сразу видны издержки на привлечение нового специалиста в проект, а также виден коэффициент, понижающий стоимость проекта при продаже. Чем больше времени надо на освоение системы, тем выше и эксплуатационные риски, и кадровые.

Жизненных примеров полно, хотя бы та же электроника, которая собирается вся на одной элементной базе.

Итак, в этой статье мы рассмотрим, как можно уменьшить количество ошибок в итоговом результате работы. Вообще, не стоит это все воспринимать как нечто догматическое, это просто мое субъективное мнение.

Разделим ошибки на категории:
1) ошибки коммуникации (например, разное понимание одного и того же термина приводят к искажению восприятия задачи).
2) Ошибки, допущенные непосредственным исполнителем в процессе реализации.
3) Ошибки, допущенные при проектировании и/или при постановке задачи. Или вообще на этапе придумывания идеи.

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

Ошибки коммуникации
Любое общение суть передача набора понятий от одного человека к другому человеку (или же от нескольких/к нескольким). Поскольку общение происходит посредством языка, а язык это набор абстрактных понятий, выраженных в словах. (Во, блин, как заумно завернул). Ну так вот, во время общения под одним и тем же словом каждый может понимать разные вещи. Чем больше актов общения происходит, тем больше вероятность ошибки. Более сложным случаем являются цепочки общения (например, заказчик высказывает пожелание менеджеру проектов, тот объясняет задачу дизайнеру, тот тимлидеру, а тимлидер разработчику). Как же уменьшить количество этих ошибок? Очень просто: нужно уменьшать количество актов непосредственно полезного общения, увеличивать качество общения, и после каждого акта составлять протокол, в котором каждый участник общения описывает своими словами договоренности, достигнутые в процессе общения, который затем проверяется каждым участником общения и каждый тезис либо подтверждается, либо опровергается. Таким образом, мы по сути увеличиваем количество актов общения как минимум вдвое. Но зато уменьшается количество ошибок, ведь каждый протокол скорее всего найдет хотя бы часть ошибок. С другой стороны протокол может вносить ошибки, поэтому каким-то образом нужно контролировать и протоколы. Например, на каждые N протоколов составлять большой сводный протокол, причем силами других людей, в котором бы излагались все тезисы из предыдущих протоколов. В целом, в большинстве компаний так и происходит, люди просто пишут друг другу письма со своим пониманием совещания.

С другой стороны, все эти согласования результатов общения сильно затягивают процесс и откладывают принятия решений и начала проектирования.

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

А это уже сильно затягивает процесс разработки и откладывает момент внедрения и эксплуатации продукта.

Ошибки проектирования
И здесь тоже причины простые. Чаще такие ошибки являются комбинацией ошибок коммуникации и исполнения на начальном этапе. Суть в том, что поскольку люди это люди, на основании правильно понятых потребностей может быть составлено ошибочное задание для исполнителя. Для избежания таких ошибок нужно проверять технические задания другими экспертами, а также постоянно проводить аудит технического состояния системы, по результатам которого выявлять противоречивые и опасные (с технической точки зрения) моменты в техническом задании.

Все это тоже может очень сильно оттянуть момент начала работы.

Что делать?
Глядя на все описанное можно сделать вывод, что внесение даже сколь-нибудь малого изменения в большую систему, да еще и при условии, что разные изменения вносятся постоянно и параллельно, может затянуться на недели или даже месяцы. Выходов тут 3:

1) Радикальный экстремизм. Вообще минимизировать всякие проверки и быть готовым быстро-быстро править-чинить. По сути, выкладывать код, который банально запускается и не удаляет все данные. 😉
2) Радикальный консерватизм: следовать всем-всем процедурам проверки и выкладывать много раз проверенный код. Подход хорош, когда нет возможности быстренько починить или же когда цена ошибки очень высока.
3) Умеренный экстремизм. В общем-то, некая комбинация первого и второго вариантов. Нужно заранее спроектировать свою систему так, чтобы ни одно изменение не могло затронуть ее целиком. Тестировать на предмет соответствия требованиям и работоспособности кода, выкладывать так, чтобы сначала изменение затрагивало только часть системы и уже после опытной эксплуатации распространять изменения на всю систему.

Лично мне ближе 3-й вариант. Похожим образом действуют, например, Facebook, ВКонтакте, Бегун, Twitter и, наверняка, еще немало хороших организаций.