Ну вобщем набросал я кое-что из мыслей. ... даже не знаю, публиковать или нет ибо прорыва в них нет, абсолютно готовых решений -- тоже. Только мысли :-).
Что я думаю по этому поводу.
Summary по проблеме.
1. Для такого рода организаций характерна работа в стиле "стихийных бедствий" и "пожарной команды". Это в отчасти происходит из-за рассинхронизации потребностей бизнсеса и возможностей ИТ подразделения. Т.е. нет согласованности -- бизнес воспринимает ИТ как "обслуживающий персонал", от которого одни расходы. И не воспринимается как полноценный партнер, который помогает бизнесу в достижении его целей.
2. Бизнес не понимает как в ИТ формируется бюджет и главное насколько эффективно этот бюджет расходуется (если конечно это интересно бизнесу). Эффективность работы ИТ подразделения измеряется «ощущениями» или только личными отношениями. Да и руководству ИТ можно поднять свой имидж если периодически совершать «подвиги» по реализации срочных проектов.
3. Из-за не восприятия бизнесом ИТ-подразделения как серьезного партнера или хотя бы как некий инструмент в достижении своих целей (со своими ограничениями – ну сложно забивать молотком сваи в землю, для этого нужны другие мощности), ИТ подразделение как правило ставят перед фактом что и когда должно быть сделано а не просят оценить и т.п. … А даже если таки просят оценить сроки/бюджеты реализации, то само руководство ИТ оценивает их исходя из тех же «ощущений», а не базируясь на метриках и статистических данных, которые характеризуют в целом процесс производства/поддержки ПО.
4. Политика и еще раз политика … распространена ситуация, когда в таких организациях «политики больше чем технологий». Этот фактор оказывает существенное влияние в т.ч. на деятельность ИТ-подразделения.
5. Кроме «внешних» факторов, есть очевидно и «внутренние» -- как то неслаженность работы различных подразделений (тех же ПМ и Аналитиков), которые, основываясь уже на собственных ощущениям и требованиям спущенным «сверху» вносят дополнительную энтропию. Они достаточно отдалены от реальной работы разработчиков и не факт, что отвечают за конечный результат. И, как это часто бывает, создавая те же ТЗ – просто «перебрасывают их через стенку» разработчикам, искренне веря что свою часть работы они уже сделали. И они не воспринимают тех же разработчиков членами одной команды, а скорее «врагами» (утрирую конечно, но где-то так). Хотя наверняка у тех же разработчиков будет масса претензий к качеству документации требований. ПМ-ы скорее всего тоже существуют обособленно, не «держа руку на пульсе разработки». И их деятельность сводится к рисованию (и частому перерисвоыванию) диаграмм Ганта и вопросов разработчикам в стиле «как дела, какой прогресс» …
6. Все вышеперечисленное является «корневыми» проблемами. От которых происходят и те «производные» проблемы конкретных исполнителей.
Возможности по решению.
1. Какое либо решение возможно при одном важном условии – осознание руководством ЧТО ПРОБЛЕМА СУЩЕСТВУЕТ и ее нужно решать. Часто в таких организациях предпочитают не изменять стиля работы а просто доплачивать исполнителями за «подвиги». И не обязательно это премирование .. это может быть просто хороший компенсационный пакет, ради которого исполнители готовы терпеть «неудобства». А если компенсируются хорошо именно «подвиги», то героизм становится просто выгодным экономически исполнителям, и большой заинтересованности в изменениях у них может и не быть, если только подвиги не приводят к нервному истощению.
2. Всем очевидно, что идеальным был бы комплексный подход к решению указанных проблем. И этот комплексный подход на стыке ITIL – P&PM – R&D SEP. Т.е. можно разработать систему сбора метрик и руководству иметь на руках цифры, которыми можно уже оперировать в т.ч. в качестве доказательной базы для бизнеса. С бизнесом определенно имеет смысл говорить на его языке – т.е. на языке KPI и денег, имея на руках численные данные. Примеры таких уже решений есть, более того сейчас такое решение оформляется в виде консалтингового продукта (я принимаю участие в этом). Практики ITIL позволят регламентировать отношения с бизнесом с т. з. качества и стоимости сервиса по разработке/сопровождению систем. Практики P&PM позволяют оценивать в т.ч. загрузку ресурсов, а Portfolio Management позволяет взглянуть на пул проектов в целом и оценить их «перспективность» в т.ч. с т.з. инвестиций в них. Третья составляющая – это собственно процессы разработки ПО, где возможно применение различных методологий и специфических практик (чуть не написал на автомате «специфических целей» … CMMI :-)). Все цели и практики Все это в комплексе позволит улучшить ситуацию.
3. Так же очевидно, что такой комплексный подход, при всей его правильности вряд ли может быть реализован в одночасье да и не факт, что будет понят и поддержан руководством (хотя есть и положительные примеры). Но к этому имеет смысл стремится. Вполне можно разработать 2 направления улучшения процессов – «сверху вниз» и «снизу вверх». Первый путь использует руководство в качестве целевой аудитории, второй – непосредственных исполнителей, в данном случае разрботчиков и «иже с ними». Из общей стратегии следует сделать (движение «сверху вниз»):
a. «Продать» идею улучшений руководству. Ее нужно грамотно спозиционировать, показать приемущества, которые можно получить в соотнесении с затратами. (Примечание. На обсуждении Дмитрий и Павел озвучили мысль, что «продавать» идею об улучшениях нужно именно в виде конкретных предложений, которые реально реализовать за короткое время.
b. Написать концепцию комплексного улучшения процессов с явным указанием целей (чего хотим достичь), работами, рисками и мероприятиями по их устранению. Цели, задачи и мероприятия должны иметь явные связи друг с другом и с рисками. Желательно подать ее таким образом, чтобы руководство сказало «О, это как раз то что я хотел предложить, только руки все никак не доходили все это структурировать и изложить» :-).
c. Активно пиарить идею об улучшениях. Причем очень желательно сделать несколько «quick win» чтобы иметь практическое подтверждение. Скорее всего эти «quick win» будут из области R&D (тут стыковка с направлением «снизу вверх»).
d. Заручившись поддержкой руководства двигаться по обоим направлениям улучшений. Делая в первую очередь то, что позволит явно показать прогресс.
4. Перейдем от «концептуального» уровня к более приземленным. В ходе обсуждения был высказан ряд рекомендаций, что можно попробовать сделать «здесь и сейчас». Я только хотел бы дополнить тем, что мне показалось возможным сделать:
a. Проблема неравномерной загрузки разработчиков. По условиям – есть взаимосвязь м/у 1) технологиями 2) специалистами владеющими технологией 3) квалификацией специалиста в данной технологии 4) «востребованностью» конкретной технологии. Чтобы решить проблему неравномерной загрузки разработчиков нужно как минимум перераспределить часть работ по конкретной технологии, но тут может выясниться что людей с такими знаниями нет – вот и мотивация чтобы отправить на курсы кого-нибудь поучиться технологии : -). Можно нарисовать матрицу Люди/Технологии … и обоснованно подходить к вопросу чтобы кол-во людей со знанием востребованных технологий было адекватным. Другой вопрос, что следует задуматься, а нужно ли в действительности такое разнообразие технологий при явной нехватке ресурсов? И кто вообще выбирает на какой технологии будет делаться конкретный (новый) проект?
b. Проблема незнания «системы в целом» и частично «переключения контекста». Тут вопрос можно рассматривать в частности с позиции архитектуры. А именно, в идеале, нужно иметь роль Архитектора проекта, который будет как раз и иметь представление о всей системе. Великолепно, если получается применять разбиение на слои (GUI, Business Layer, Persistence Layer, Data Layer). Унификация даже на таком уровне позволяет существенно упростить представление о системе и переключатся становится проще и специализация не помеха. Что для этого нужно? В первую очередь выстроить внятно Разработку и управление требованиями (RDM), и Управление изменениями и конфигурациями (SCCM). В данном случае не важно на базе какой методологии это будет сделано. Второе – это, как минимум для новых проектов стараться использовать унифицированных архитектурный стиль. Наличие хорошо сформулированных требований и четкого дизайна системы (когда бизнес-логика не размазана по GUI и хранимым процедурам) существенно упростит жизнь и позволит быстрее подключать новых специалистов к проекту. Это конечно хороший и правильный совет, но не всегда он может быть выполнен :-). Хотя есть примеры, когда требования в организации восстанавливали для систем, иначе невозможно было их тестировать.
c. Еще один, тоже прозвучавшая в ходе обсуждения рекомендация – разграничение ответственности. Тут кстати, в качестве формального представления может быть полезна т.н. матрица ответственности или RACI charts (см. COBIT 4.0).
Есть другой взгляд на проблему, исходя из «объективной реальности». Примем, что системно/комплексно мы не можем подойти к вопросу улучшения процессов. Так же примем как данность, на которую мы не коим образом не можем повлиять, тот факт, что задачи сваливаются хаотично, что требования к системам низкого качества, и что есть разброс технологий. ПМ-ы и аналитики по сути наши прокси-заказчики и разработчики не имеют выход на реальных заинтересованных лиц. Считаем, что Аналитики никак не заинтересованы в результатах проекта в целом. Имеем в качестве исходных данных перечисленные Денисом проблемы. Что можно сделать в этом случае?
1. Глобально – инкорпорировать ПМ-ов и аналитиков в единую команду – они должны плыть в одной с вами лодке и разделять успех/неуспех вместе с разработчиками.
2. В условиях дефицита ресурсов нужно равномерно распределить нагрузку, в т.ч. по технологиям. Как это можно сделать уже обсуждалось. Добавлю, что нужно инвестировать в повышение квалификации разработчиков.
3. Воспринимать поступающие ТЗ только как «исходные сырые материалы», и самостоятельно разрабатывать требования (пусть в виде списков фич или назовем это бэклогом, не столь важно) и включать эту активность и время на нее в планы работ. Для чего? Чтобы обратить внимание на то, что требования поступают ненадлежащего качества и приходится их перерабатывать, а на это уходит время и соответственно удлиняется разработка. Альтернатива – научить аналитиков делать внятные требования к софту и унифицировать документацию и принципы разработки требований и инкорпорировать их в проекты, чтобы они взяли на себя часть нагрузки.
4. Регистрировать ВСЕ задачи, которые поступают и учитывать время их исполнения. Можно возложить на начотдела такую работу. Сдвигать графики в при возникновении срочных задач с уведомлением заказчиков о причинах. Это в т.ч. позволит обоснованно говорить о возможных сроках реализации – «приходите через полгода» (цитирую Дмитрия).
5. И конечно же, как отметили многие присутствующие на этом обсуждении следует рассмотреть вопросы формирования команды. Эффективно работать в такой ситуации можно только со сформированной командой. Практики летучек, итераций эффективны либо при жестком управлении либо в сплоченной команде (результат примерно одинаков, но в самоорганизующейся команде это более эффективно и у всех положительные эмоции).
Семинар AgileRussia: Применимость agile-методик в in-house-разработке