Ярослав Перевалов
yar-home@yandex.ru
Процесс проектирования и разработки как проекция методологии в пространстве Компания-Проект-Команда
Рано или поздно любая компания, разрабатывающая программное обеспечение, пытается усовершенствовать свои процессы, подняться на ещё одну ступеньку от кустарного производства к индустриальному (не от слова «индус», а от слова «индустрия»). Индустриальное производство характеризуется наличием развитых технологий и стандартов. Почему же такое движение не прекращается и достижима ли цель вообще? Какие трудности в достижении этой цели возникают у компаний?
Рис. 1. Даёшь индустриальное производство! (плакат времён индустриализации)
Один из наиболее распространённых способов «продвинуть» производство ПО – применить ту или иную передовую методологию разработки на практике, т.е. в условиях конкретной компании, проектов и команд.
«Если у других работает, значит, и у нас заработает!», — провозглашает идейный вдохновитель очередной индустриальной революции, прочитав книгу с описанием передовой методологии.
Рассмотрим поподробнее, как выглядит внедрение абстрактной методологии и превращение оной в рабочий процесс, какие трудности поджидают внедренцев на этом пути.
Внедрение методологии происходит на нескольких уровнях, имеющих свои ограничения, особенности и условия, см. Табл. 1.
Табл. 1. Ограничения, особенности и условия, влияющие на внедрение новой методологии разработки ПО
|
Уровень |
Факторы, влияющие на внедрение |
|
Компания |
Ресурсы, Вид бизнеса, Традиции, Уровень развития корпоративной культуры производства, Прогрессивность менеджмента, Источник революции (сверху или снизу), Отношение к стандартизации. |
|
Проект |
Потребности бизнеса, Особенности Заказчика, Ресурсы, Уникальность проекта. |
|
Команда |
Ресурсы, Уровни компетентности сотрудников, Консерватизм, Зоны ответственности, Традиции, Понимание цели внедрения, Прочие человеческие факторы (коммуникативные, социальные, психологические и пр.). |
Эта табличка поможет революционерам задуматься о возможных трудностях и проблемах, с которыми они могут столкнуться, и подстелить соломку, а, может быть, придумать мероприятия, снижающие риски в наиболее опасных местах.
Таким образом, при внедрении общей-абстрактной методологии проектирования и разработки, эта методология претерпевает существенные изменения и модификации, как правило, в сторону упрощения. Этот эффект я называю проекцией: например, проекция шара на плоскость – это круг, ну и т.д. Хитрость заключается в том, что при переходе с уровня на уровень проекция меняется – добавляются новые модифицирующие факторы, см. Рис. 2.
Рис. 2. Процесс разработки как третья проекция методологии
Казалось, бы, всё просто и очевидно. Хитрости начинаются на этапе, когда заказчик индустриализации осознаёт, что круг – это не шар. Следующее открытие – в одном случае проекция получается в виде круга, а во втором – проекция этого же самого объекта – прямоугольник (вспоминаем школьный фокус на уроке черчения с цилиндром). Добивает революционеров осознание того, что проекция тройная, т.е. проекция претерпевает тройное изменение (Компания-Проект-Команда).
Выводы из этой простой математической модели следующие:
- Процессы, реализованные по одной методологии, но в разных компаниях – разные.
- Процессы, реализованные по одной методологии в одной компании, но на разных проектах – разные.
- Процессы, реализованные по одной методологии, в одной компании, в одном проекте, но разными командами – разные.
Ничего удручающего в принципе в полученных выводах нет, надо просто учитывать этот эффект, затевая очередную революцию. Учёт должен выражаться в коррекции цели революции, ожидаемого эффекта и применении дополнительных мероприятий (например, введение или наоборот, устранение некоторых регламентов).
На этом можно было бы поставить точку, но возмущённый читатель потребует реальных примеров и баек на этот счёт. На самом деле, за абстрактными «факторами» из таблички стоят реальные примеры и истории, но очень уж долго все их перечислять.
Приведу лишь несколько примеров возможных проблем, по одному на каждый уровень.
1. Уровень компании. У меня был опыт, когда меня наняли как крутого юзабилити-консультанта в одну компанию, видимо, в надежде, что у продуктов заметно поднимутся потребительские качества. Поскольку в штатном расписании не было должности «юзабилист», меня поставили в подчинение дизайнеру, который хоть что-то понимал в юзабилити. Дизайнер, в свою очередь, работал в отделе технической документации, потому что помогал писателям оформлять иллюстрации. Менять процессы в кампании передо мной задачи никто не ставил, и соответствующих ресурсов никто не давал. Скажите, сможет ли старший помощник младшего дизайнера повысить качество продукции компании? Ответ очевиден. Хотя сама по себе юзабилити – очень хорошая инженерная дисциплина, да.
2. Уровень проектов. Если вы делаете какой-то уникальный проект по некоторой методологии, не тешьте себя мыслью, что полученный успешный опыт вы сможете эффективно применить на других (совсем не похожих на этот) проектах. Просто не тешьте себя, и всё. Индустриальные технологии хороши для массового производства, а кустарные – для штучного. Вы будете штамповать свои проекты сотнями, тысячами, миллионами?
3. Уровень коллектива. Например, начальник – не очень далёкая женщина, любящая строить карьеру. Любые решения этот начальник принимает, руководствуясь своими внутренними ощущениями и не очень заботясь о том, чтобы «солдат понимал манёвр». И новых сотрудников она нанимает не столько по профессиональным компетенциям, сколько из соображений личной преданности. Всё это делается под дымовой завесой передовых технологий. Дальше продолжать не буду, сами сможете легко спрогнозировать ситуацию.
Хм. Какая-то не очень весёлая картина вырисовывается. Должны же быть и положительные стороны любого прогрессивного движения. Попробуем отыскать рациональное зерно.
1. Стремление к правильному процессу лучше, чем отсутствие процесса вообще. Порядок лучше хаоса. Само наличие понимания, что процесс существует и его можно усовершенствовать – достойно уважения.
2. Можно в схему безболезненно добавить ещё одну методологию, и ещё несколько, т.е. ваш реальный процесс в вашей компании на вашем проекте и вашем коллективе – очень гибкая штука, которую можно и нужно подстраивать и модифицировать на лету. Всё равно после тройной проекции сложно узнать прародителя. Если прародителей будет несколько – это нисколько не повредит. Избегайте канонов в построении процессов, и тем паче избегайте людей, которые эти каноны проповедуют и горло готовы перегрызть за их формальное соблюдение. Важные критерии – целесообразность и эффективность, а не соответствие «чистым канонам избранной методологии». Если что-то хорошо работает – это правильно. Избегайте «ложного» положительного опыта. Что работало в других условиях, может не выстрелить здесь и сейчас.
3. Люди, имеющие опыт работы по «правильным» процессам, обогащают коллектив и производство. К сожалению, верно и обратное – люди, работающие по «неправильным» процессам, портят коллектив и производство. Кроме того, остаётся открытым вопрос – какой процесс считать правильным. Тут я бы посоветовал руководителям сверять описание процесса соискателя со своим личным представлением об идеальном процессе. Если в целом и общем есть совпадение – есть шансы на успех.
4. Получив хороший эффект или процесс на выходе, смело называйте его своим именем или именем своей компании. Как было сказано, прародителей если и будет видно, то всё равно это ваше детище, которым можно и нужно гордиться. В качестве примера можно почитать статью о процессе аналитической поддержки имени Ярослава Перевалова и компании RapidSoft.
Статью можно обсудить в ЖЖ автора.
Дата публикации: 27 августа 2012 г.
©Usability.Ru
Публикация материала только с согласия автора. При публикации ссылка на Usability.Ru обязательна!