Главная картинка статьи №11

О важности применения шаблонов в профессии аналитика, как путь к содержательному творчеству

О применении шаблонов

Оригинально об избитом

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

Беда была (а для многих есть) прозаично проста. Значительную часть своих усилий ИИ постоянно расходовал на обдумывание и реализацию не конкретного замысла, решения возникшей задачки, а на то, как отобразить эту идею в доходчивой, для его подчиненных собратьев по проектно-внедренческой команде, форме.

Дело в том, что его свита была очень интеллектуальна, но разношерстна. Её собирали, как принято выражаться, «с hh.ru (и подобных интернет порталов) по нитке» и каждый из её участников представлял из себя уникального специалиста, но был уникален не только своими способностями, навыками, скилами но и языком/диалектом, на котором каждый конкретный индивид изъяснялся.

Это являлось причиной того, что им приходилось общаться между собой на универсальном псевдоязыке формальных структур и чисел. Каждый раз они совместно были вынуждены разрабатывать и внедрять в свое общение новационные «языковые» структуры, которые были всем однозначно понятны. Иначе успех всех «жизненноважных» инновационных мероприятий находился бы под угрозой срыва из-за отсутствия понимания проблемы коммуникаций. Её можно было бы решить, если кто-то из всей этой элитарной собратии, догадался посоветовать ИИ один раз переписать наиболее удачные структуры общения и трудиться в соответствии с ними в дальнейшем. Реакция ИИ, по умолчанию, должна быть положительной, ведь это в его интересах :).

Наши дни

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

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

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

Обзор инструментов

Стоит немного поговорить о существующих инструментах, их преимуществах и недостатках.

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

Помимо коммерческой подоплеки, многообразие методологий связано с тем, что каждая из них имеет разное специальное назначение и цель.

Многие из них это эволюционные ступени одной лестницы, к примеру можно упомянуть следующие:

  • ITILv.1 -> ITILv.2 -> ITILv.3
  • СММ -> SPICE -> CMMI
  • и т.д.

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

Другие, это взгляд на разные этапы ИТ процессов под разными углами, учитывающими специфику конкретной ситуации:

  • ISO/IEC 12207
  • ISO/IEC 15288
  • и т.д.

Некоторые - это адаптация конкретной деятельности в зависимости от типа конкретного проекта и критичности отражения в нем тех или иных аспектов:

  • Шаблон спецификаций в соответствии с IEE 830
  • Шаблон спецификаций в соответствии с методологией RUP

Это многообразие связано с множеством дополнительных и разнообразных факторов по применению конкретного инструмента.

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

Адаптируй под себя

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

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

НО…

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

Для рабочего процесса недостатки состоят в том, что слишком выверенным инструментом сможет пользоваться 1-2 специалиста, не больше. При смене исполнителя / группы исполнителей «под кого» создавался данный инструмент, есть вероятность того, что пришедшие на их место работники будут не в состоянии понять, освоить, и что самое главное – применять его. Если процесс работы с ИТ инструментами в компании организован грамотно, то существующая документация пользователя позволит минимизировать данный тип риска, но, если речь идет о небольших и средних типах компаний, то, как правило, данным видом рабочей активности пренебрегают сознательно в целях экономии ресурсов. Как показывает время и опыт – зря. Когда создаваемый инструмент становится уникальным, то надо помнить о том, что любая уникальность стоит дополнительных расходов на его содержание, обслуживание и развитие.

Для специалиста минусы «подгонки» заключаются в том, что они влекут порождение косности и консерватизма взглядов. Каждый процесс, со временем, становится на «устоявшиеся рельсы» своего пути. Если на этом пути, каким бы долгим и кривым он не был, машиниста всё устраивает, то он считает, что он в идеальных рабочих условиях, так как существующим транспортом он доберется из пункта «А» в пункт «B» за заданное количество времени. Успокоенность условиями процесса может «убаюкать», что приводит к тому, что «вовремя непереведенные стрелки» пустят поезд под откос. Не пересматриваемые характеристики процесса, отсутствие отлаженной активности совершенствования деятельности приводит к тому, что работники надевают на себя рабочие «шоры». Для какого-то вида деятельности это неплохо, но количество «шор» надо контролировать и правильно ими управлять. Когда их становится слишком много …, в общем, помним о принципе «золотой середины» :).

Итого:

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

Заключение

Так что же такое шаблоны и как к ним относится?

Каждый из профессионалов, использующий их в своей деятельности, ответить на этот вопрос наиболее оптимальным для себя образом:

  • Для кого-то это инструмент, который позволит упростить операционный труд в рамках процессной и проектной деятельности
  • Для кого-то это возможность сосредоточиться на более важных, для результата деятельности, вопросах, а работу по представлению информации передать шаблонам, о правилах работы с которыми заранее договариваются между собой участники, использующие их в работе
  • Для кого-то это основная часть его работы, на которой основан принцип и результат его работы
  • …(впишите своё)

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

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

Авторы статьи

Иван Никитин

Михаил Цулая