Итак, в этой статье мы рассмотрим, как можно уменьшить количество ошибок в итоговом результате работы. Вообще, не стоит это все воспринимать как нечто догматическое, это просто мое субъективное мнение.
Разделим ошибки на категории:
1) ошибки коммуникации (например, разное понимание одного и того же термина приводят к искажению восприятия задачи).
2) Ошибки, допущенные непосредственным исполнителем в процессе реализации.
3) Ошибки, допущенные при проектировании и/или при постановке задачи. Или вообще на этапе придумывания идеи.
У каждой категории ошибок есть свои причины, влияющие на их количество и характер. Причем независимо от типа работы (проект или процесс) сами ошибки не меняются. Попробуем рассмотреть эти причины и способы влияния на них.
Ошибки коммуникации
Любое общение суть передача набора понятий от одного человека к другому человеку (или же от нескольких/к нескольким). Поскольку общение происходит посредством языка, а язык это набор абстрактных понятий, выраженных в словах. (Во, блин, как заумно завернул). Ну так вот, во время общения под одним и тем же словом каждый может понимать разные вещи. Чем больше актов общения происходит, тем больше вероятность ошибки. Более сложным случаем являются цепочки общения (например, заказчик высказывает пожелание менеджеру проектов, тот объясняет задачу дизайнеру, тот тимлидеру, а тимлидер разработчику). Как же уменьшить количество этих ошибок? Очень просто: нужно уменьшать количество актов непосредственно полезного общения, увеличивать качество общения, и после каждого акта составлять протокол, в котором каждый участник общения описывает своими словами договоренности, достигнутые в процессе общения, который затем проверяется каждым участником общения и каждый тезис либо подтверждается, либо опровергается. Таким образом, мы по сути увеличиваем количество актов общения как минимум вдвое. Но зато уменьшается количество ошибок, ведь каждый протокол скорее всего найдет хотя бы часть ошибок. С другой стороны протокол может вносить ошибки, поэтому каким-то образом нужно контролировать и протоколы. Например, на каждые N протоколов составлять большой сводный протокол, причем силами других людей, в котором бы излагались все тезисы из предыдущих протоколов. В целом, в большинстве компаний так и происходит, люди просто пишут друг другу письма со своим пониманием совещания.
С другой стороны, все эти согласования результатов общения сильно затягивают процесс и откладывают принятия решений и начала проектирования.
Ошибки исполнителя
Тут причины простые: люди иногда ошибаются и такова природа. Программист может где-то неправильно реализовать логику или не учесть какую-то ситуацию. Выход простой: тестировать перед тем, как использовать в жизни. В случае с кодом ситуация особенно показательна: на сам классы пишутся юнит-тесты, затем на сам код пишутся (или проводятся руками) функциональные тесты, затем на всю систему пишутся (ну или же опять-таки руками делаются) интеграционные тесты. Однако, если проект большой, то есть вероятность, что в тестах будет ошибка, которую пропустит ошибку в коде или в классе. А значит, все тесты надо покрывать тестами и так далее, такое рекурсивное тестирование.
А это уже сильно затягивает процесс разработки и откладывает момент внедрения и эксплуатации продукта.
Ошибки проектирования
И здесь тоже причины простые. Чаще такие ошибки являются комбинацией ошибок коммуникации и исполнения на начальном этапе. Суть в том, что поскольку люди это люди, на основании правильно понятых потребностей может быть составлено ошибочное задание для исполнителя. Для избежания таких ошибок нужно проверять технические задания другими экспертами, а также постоянно проводить аудит технического состояния системы, по результатам которого выявлять противоречивые и опасные (с технической точки зрения) моменты в техническом задании.
Все это тоже может очень сильно оттянуть момент начала работы.
Что делать?
Глядя на все описанное можно сделать вывод, что внесение даже сколь-нибудь малого изменения в большую систему, да еще и при условии, что разные изменения вносятся постоянно и параллельно, может затянуться на недели или даже месяцы. Выходов тут 3:
1) Радикальный экстремизм. Вообще минимизировать всякие проверки и быть готовым быстро-быстро править-чинить. По сути, выкладывать код, который банально запускается и не удаляет все данные. 😉
2) Радикальный консерватизм: следовать всем-всем процедурам проверки и выкладывать много раз проверенный код. Подход хорош, когда нет возможности быстренько починить или же когда цена ошибки очень высока.
3) Умеренный экстремизм. В общем-то, некая комбинация первого и второго вариантов. Нужно заранее спроектировать свою систему так, чтобы ни одно изменение не могло затронуть ее целиком. Тестировать на предмет соответствия требованиям и работоспособности кода, выкладывать так, чтобы сначала изменение затрагивало только часть системы и уже после опытной эксплуатации распространять изменения на всю систему.
Лично мне ближе 3-й вариант. Похожим образом действуют, например, Facebook, ВКонтакте, Бегун, Twitter и, наверняка, еще немало хороших организаций.