Привет, Хабр! На связи Михаил Персианов, разработчик сопровождения. Сегодня мы с Оппонентом приглашаем к дискуссии по стандартам и правилам, на которых строится разработка и проект 1С.

В нашей работе много разных стандартов: есть международные стандарты управления проектами, стандарты разработки 1С, почти у каждого руководителя проекта и техархитектора есть свои наработки по стандартам и регламентам ведения проекта. Компании с пятилетним стажем, как правило, уже имеют какой-то корпоративный стандарт.

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

Оппонент:

Руководителям проектов привет!

Автор:

Не только РП отвечают за стандарты. Составлять их и контролировать исполнение могут архитекторы, тимлиды, и даже администраторы проектов. Но при этом работает со стандартами вся команда. Поэтому определю не должности, а болевые точки.

Постараюсь помочь вам:

• ответить, когда и зачем нужен стандарт;

• справиться, если стандарт мешает;

• победить основные ошибки стандартов;

• понять, когда стандарт даёт сбой;

• составить стандарт из шаблона.

Мы обсудим:

• какую пользу ждём от стандартов;

• какие мы получаем минусы;

• возникающие замечания и составим проверочные списки;

• а нужны ли стандарты вообще?

Преимущества стандартов

Начну с целей применения:

• В стандартизированных ситуациях не раздумывают даже новички — существенное ускорение процессов.

• Исчезают конфликты между действиями участников (я делаю так, а ты иначе, кто прав?) и путаница (например, когда каждый составляет документацию, как хочет).

• Если требуется разобраться в действиях участника или повторить их, то проще искать ошибки и меньше зависимость от конкретного участника.

• Управлять намного проще, когда действия каждого участника запланированы и предсказуемы. Стандарт обеспечивает единый язык и прозрачность для команды проекта и даже заказчика.

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

• Сертификация на соответствие известному стандарту привлекает новых клиентов.

• Составление документации для заказчика упрощается, когда она делается на основании стандартной документации проекта.

Также неплохо получить и косвенные преимущества:

• Хороший стандарт является частью базы знаний проекта, корпоративной базы управления проектами, аналитики, разработки.

• Оценка задач и проекта упрощается, когда действия стандартны, порядок действий известен, и по каждому действию уже есть база фактических исполнений.

• Стандарт накапливает опыт команды. Он позволяет избежать ошибок, с которыми, возможно, отдельные участники не сталкивались ни разу.

• Хороший стандарт позволяет уменьшить техдолг.

Пример:

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

Оппонент:

Не забудь сказать, что без стандарта техдолга вообще не будет.

Автор:

Не скажу. Техдолг будет, но назовут его иначе. И ещё будет путаница. А со стандартом понятно, что и когда можно оставить техдолгом, как хранить информацию о нём, в каком порядке и как его закрывать.

Недостатки стандартов

Отрицательное отношение стандарты вызывают довольно у многих:

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

• Любителей сделать быстренько как-нибудь стандарты существенно замедляют.

• Они нередко противоречат привычкам опытных разработчиков.

• Растёт порог входа и время адаптации, что расстраивает любителей посчитать деньги.

• Нередко требуется время на приведение к стандарту.

Вы работали в проекте с применением стандартов, и ни разу не ругались на стандарт? Вам повезло. Я ругался неоднократно.

Оппонент:

Я продолжу! Не раз встречал в проектах абсурдные требования. Например, техзадание из трёх разделов: для Заказчика, для разработчика и для инструкций пользователю. В контексте моего проекта это было тройное повторение текста. Но если находилась ошибка, то её не только требовалось пересогласовать, так ещё и трижды исправить. Надо тебе рассказывать, какие усилия прикладывали участники, чтобы скрывать ошибки?

Или неприменимые правила, сохранившиеся с прошлого проекта…

Автор:

Сначала — про ошибки состава и практики применения:

• Стандарт содержит абсурдные требования.

• Требования стандарта противоречат друг другу.

• В стандарт попали скопированные из других стандартов невыполнимые требования. Нередко их добавляют для сертификации.

• Требования выполнимые, но противоречащие здравому смыслу.

• Заменять стандарты разрозненными инструкциями в письмах и чатах неинформативно и неудобно: найти что-то нужное нереально, кто из вновь прибывших что сумел прочитать — непонятно.

• Неоптимальность стандартизированных процессов.

• Неоправданно жёсткие стандарты.

Оппонент:

И всё же ты пропустил главную ошибку: строгость закона не должна компенсироваться необязательностью его применения.

Автор:

Если это и не главная ошибка, то самая частая — точно. Уж не знаю, по какой причине. Лень делать как надо? Злоупотребление (знают, что потом всё равно оставят как есть, так как исправлять трудозатратно, максимум — замечание сделают)? Отсутствие контроля? Нежелание изучить стандарт? Невозможность найти в нём нужное? Причин может быть много. Включаю в список.

Оппонент:

Добавлю про «невозможность найти». Большой стандарт — тоже ошибка.

Автор:

Не согласен. Дело не в размерах. Наоборот, удобно, когда на любой вопрос можно быстро найти ответ. Но ключевые слова «быстро найти». Я ранее говорил, что стандарт — база знаний. И требования к нему тоже как к базе знаний, в том числе — удобный поиск. Поэтому переформулирую пункт про разрозненные инструкции:

• Заменять стандарты разрозненными инструкциями в письмах и чатах неинформативно и неудобно: найти что-то нужное нереально, кто из вновь прибывших что сумел прочитать — непонятно.

• Требования стандарта фактически не выполняются.

• Неудобство пользования стандартом.

Вспомнил ещё одну ошибку: необоснованность. Есть мнение, что в каждом пункте надо писать, для чего этот пункт придуман. В каждом — точно перебор, бывают вполне очевидные пункты.

Оппонент:

Я бы вообще сказал, что это лишнее. Зачем эта информация в стандарте?

Автор:

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

Оппонент:

А теперь мои пункты против применения стандартов в принципе:

• Любой стандарт отвергает новое. А вдруг я лучше процесс придумал?

• Стандарт делает проект дороже: участники тратят время на изучение стандарта и приведение своих действий в соответствие.

• Исполнителям стандарт не всегда удобен: если я 10 лет успешно работал по иной схеме, зачем перестраиваться на неудобные и сомнительные алгоритмы?

• Стандарты — лишняя бюрократия и трудозатраты. Если руководитель в состоянии контролировать выполнение каждой задачи безо всяких стандартов, с заказчиком прекрасные отношения, и он тоже против лишних усилий.

И основной вопрос: зачем мне вообще стандарт? Я видел много успешных проектов, в которых совсем стандартов не было.

Автор:

Стандарт не отвергает новое. Он должен быть «живым», своевременно меняться в обоснованных случаях. Должен быть баланс. Каждое изменение стандарта — затраты как минимум на доведение изменений до команды. Но бывают и неоправданно жёсткие стандарты.

Пример:

Лет 10 назад подтверждённое соответствие PMBOK считалось преимуществом проекта. Но здесь палка о двух концах: соответствие PMBOK подтверждает, что в проекте нет неконтролируемого беспорядка, однако далеко не все инструменты PMBOK наиболее эффективны в случае конкретного проекта. Иногда разумнее воспользоваться другими схемами. И заказчик, захотевший увидеть сокровенный сертификат, дважды за это раскошеливается: сертификат, хоть и косвенно, он тоже оплатит, как и невозможность выбрать инструмент.

Оппонент:

Но контролировать проект и подтвердить компетенцию исполнителя тоже хочется. Что делать?

Автор:

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

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

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

Пример:

При запуске проекта решили не вводить стандарт, или вводить его позже, чтобы освободить время для решения задач. Рассмотрим только одно правило: как комментировать изменения в коде. Комментарии в доработанную конфигурацию вносят пять человек:

• Андрей — комментирует код, указывая только своё имя, начало и окончание;

• Борис — в начале комментария дополнительно указывает организацию;

• Валентина — откладывает вставку комментария на потом, когда определятся правила;

• Георгий — спрашивает техлида;

• Дмитрий  — спрашивает РП.

В результате два руководителя потеряли время, Георгий и Дмитрий позже поспорили из-за формата, и в разборки вовлекли техлида, РП и остальных трёх разработчиков. Валентина забыла добавить комментарии, при обновлении код пропал, это вовремя не заметили и потом пришлось искать ошибку, исправлять код и испорченные данные. Ещё при обновлении из кода Бориса исчезла вся середина, так как обновляющий не заметил в начале кода, что это начало фрагмента, и взял только одну строчку. Код Андрея не попал в релиз, так как сборщик при сравнении с другой веткой решил, что код этот из старых доработок и его нужно удалить.

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

Как использовать стандарт, чтобы получить максимальную отдачу

Правила составления стандарта с учётом перечисленных выше замечаний:

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

• Новые пункты добавляются для достижения каких-то целей.

• Стандарт должен быть понятным и достаточно подробным.

• Он должен быть обоснованным: помогать, облегчать работу, а не осложнять и запутывать её. В частности, там, где действия участников по своему усмотрению никому и ничему не мешают, — ограничения не нужны. Там, где допустимы варианты, — они должны быть разрешены.

• Стандарт должен быть, по возможности, полным. Чем больше проблем он решает, тем лучше.

• Стандарт должен быть лаконичным.

• Чтение и поиск должны быть удобными. Прекрасно, если каждый участник может найти необходимую ему информацию быстро и прочесть её в одном месте в компактном виде.

• Отклонения от стандарта должны быть допустимы в строго обоснованных случаях. Они могут быть разовыми, условными либо постоянными в рамках проекта (требование заказчика или эксперимент).

Для обеспечения корректности состава стандарта:

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

• После исправлений дайте кому-нибудь прочитать стандарт и высказать замечания.

• Исправленный вариант обсудите командой.

• Спорные моменты — на волевое решение руководителя/

Для использования стандарта:

• Должна быть процедура быстрой и удобной корректировки стандарта, в том числе корпоративного, подразумевающая и оповещение пользователей.

• Есть положительная практика, когда участники после сложных случаев сами составляли новые разделы стандарта.

• Хорошо зарекомендовавшие себя новшества должны транслироваться в корпоративный стандарт.

• Стандарт должен храниться в формате, обеспечивающем актуальность, удобство поиска, чтения и использования: избранное, экспорт шаблонов и так далее.

• Прекрасно, если процессы по стандарту будут автоматизированы.

Оппонент:

А как понять, что стандарт даёт сбой?

Автор:

Первый индикатор — прямые обращения. Если участники команды жалуются на стандарт и связанные с ним проблемы, это тоже признак неоптимальности.

В остальном — как и для любого другого инструмента. Инструмент нужен для достижения цели. И сбой означает, что цель не достигнута или достигнута с замечаниями. Далее ищем причины и устраняем их.

Если стандарт связан с результатом, то для проверки желательно иметь автоматизированный инструмент и два уровня его использования:

• Самопроверка. Исполнитель задачи — человек, а человек ошибается, и инструмент поможет ему найти ошибки.

• Контроль. Проверка результата, переданного исполнителем задачи. Если здесь обнаруживаются ошибки, то это сигнал, что что-то идёт не так.

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

Оппонент:

А метрики есть? Как мне измерить влияние стандарта?

Автор:

Вопрос непростой. Для изменений стандарта конечно же, логично, измерить зависящие от него операции до и после изменений. Чаще всего метрика — это трудозатраты, но может быть, например, и количество замечаний от Заказчика, всё зависит от цели изменений.

А вот с уже работающим стандартом сложнее. Смысла временно отменять его правила ради замера, конечно же, нет.

Общим неплохим инструментом являются метрики трудозатрат отдельных операций, но это тема для отдельной статьи.

Выводы:

• Без стандарта можно выполнить маленький, «семейный» проект, но уже в среднем по размерам проекте без стандарта очень трудно.

• Правила составления и использования стандарта описаны выше.

• Стандарт — это инструмент в ваших руках, и вы им управляете. Ориентируйтесь на контекст, используйте опыт и разум — ваше главное оружие.

Всем — результативных проектов с гениальными стандартами!