Системный анализ в IT

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

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

2. Синергетический
Создание продукта происходит посредством определённым образом организованной коллективной деятельности команды профессионалов в разных областях, касающихся данного продукта. Каждый из них не обязан быть абсолютным экспертом, скорее должен превосходить уровень специалиста и уметь работать в команде. Команда формируется не только на основе профессиональных компетенций, но и командных ролей. Одна из ключевых составляющих такой работы – опытный куратор команды, который её формирует и организует её работу. Главная особенность синергетического подхода – частые мозговые штурмы, перемежающиеся этапами сбора и отработки различных идей. На мой взгляд, команда может давать результаты, близкие к идеальным и достаточно быстро. Другое дело, что ресурсная стоимость создания и поддержания такой команды достаточно высока, такой подход могут позволить себе немногие в индустрии. Антипаттерн – Design by Commitee.

3. Процессный
Подход на основе разделения зон ответственности и специализации, когда работа строится на основе ИСР, workflow, где каждую операцию выполняют отдельные специалисты довольно длительное время и передают результаты следующему специалисту. Понятно, что креативность и гениальность здесь минимальны, вероятность создать идеальный продукт невелика, но зато есть возможность стабильно воспроизводить “новый” продукт с некоторым приемлемым уровнем качества. Также велика роль постановщика процессов, хотя при отработке конвейера он может устраниться из процесса. Требования к специалистам самые малые.

NB: Такой перечень подходов немного напоминает типовые оргструктуры по Минцбергу и стадии развития организации по Адизесу.

Кстати, выстроилась некоторая очевидная, наверное, секвенция: Эксперт > Профессионал > Специалист.

Я в основном в своей жизни участвовал в процессных и псевдо-экспертных подходах (когда человек пытается всё сделать сам, экспертом не являясь).

Сообщество AgileRussia проводит открытый семинар на тему «Методология Scrum»
13 сентября, в 19.00 на территориии офиса Luxoft

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

В нашей программе две части:
«Обзор методологии Scrum» и «Внедрение Scrum: Опыт одной компании».

Обзор методологии Scrum

1. Зачем нужен Scrum?
2. Основа методологии Scrum
3. Роли, артефакты и жизненный цикл
4. Преимущества и применимость методологии

Ведущий – Асхат Уразбаев

Внедрение Scrum: Опыт одной компании

1. Состояние до внедрения Scrum
2. Внедрение Scrum
3. Трудности, с которыми мы встретились
4. Как мы с ними справлялись
5. К чему стремимся сейчас

Ведущий – Никита Филиппов

Семинар бесплатный, чтобы на него — запишитесь здесь по кнопке [Участвую], указав при регистрации в системе свои реальные ФИО (этого требует пропускная система Luxoft).

AgileRussia Community

13 сен	Семинар – Методология Scrum Luxoft, 13 Сентября 2007 в 19:00:01 (Москва, Россия)

На диаграмме представлена текущая Оргожаба подразделения разработки систем.
На входе у Оргожабы – вселенский ХАОС.
На выходе – новый, с иголочки, блистательный, функциональный, супернадёжный и удобный ПРОДУКТ.

(по ссылке доступна версия в формате обоев для рабочего стола).

Лица с богатым воображением могут развить анималистические аналогии, например:

• Менеджеры (М) – это глаза Жабы, обозревают Хаос, координируют, спасают от опасностей,
• Аналитики (Ан) – рот и нос, тщательно впитывают и разжёвывают Хаос, превращая его в постижимую материю,
• Архитекторы (Ар) – мозг и сердце, заставляют Жабу существовать и двигаться,
• Разработчики (Р) – лёгкие, желудок, печень и т,д., выполняют жизненно важные функции,

ну и т.д., но все эти фантазии останутся на совести воображающего.

Я исхожу из такого текущего состава Жабы (всего ~20 человек):

• 2 менеджера
• 2 аналитика
• 2 архитектора
• 4 верстальщика
• 8 программистов
• 2 тестировщика
• 1 инженер поддержки

Линии между сотрудникам означают наиболее активные коммуникации (на мой взгляд).

Жаба (Ж) стоит перед непростым выбором. Команда переезжает в новый офис.
В нём есть 2 помещения, ориентировочно на 8 и 12 человек (или 6 и 14).
Итого – Жабе предстоит разделиться на две части

Есть 2 принципиальных варианта:

1. Почкованием – в результате получим Большую и Малую Жабу, по форме и свойствам похожую на текущую.
2. Ядерным делением – в результате получим 2 абсолютно новых существа пока неизвестных биологических видов.

Предлагаю вам принять посильное участие в судьбе зверька.

В пятницу, 16-го числа в офисе компании Luxoft прошла очередная встреча сообщества AgileRussia, которое создано и развивается силами Асхата Уразбаева.

Я представлял тему для разбора кейса – “Применимость Agile-методик в условиях in-house разработки”.

Я описал свою рабочую ситуацию, исходя из предположения, что многие вещи схожи для IT-подразделений отраслевых компаний, на что потратил довольно много времени и продолжал пояснять уже по ходу обсуждения и высказывания идей/рекомендаций

Ситуация выглядит примерно так:

В течение нескольких лет команда из 7 разработчиков, использовавших единый фреймфорк на стеке html-php-postgres, создавала веб-порталы и постепенно мигрировала в IT-подразделение крупного предприятия. За это время произошли следующие изменения:

• Сократилось число людей в команде – теперь это 4 опытных специалиста (7-10 лет опыта) + 4 средней квалификации (3-5 лет).
• Т.к. в компании много разных систем, то сильно диверсифицировались используемые технологии – SharePoint/С#, веб-сервисы, Oracle, XML/XSD/SQLXML, Businesss Objects, BizTalk.
• Каждый сотрудник стал участвовать сразу в нескольких (2-5) проектах по созданию, развитию и доработке систем.
• Возникла специализация по технологиям из-за невозможности хорошо знать всё – каждый спец хорошо знает 2-3 технологии + разбирается в ещё 3-4, как следствие, специалисты распределились по модулям систем и никто не знает каждую систему целиком.

В организационной части наблюдаются следующие эффекты:

• Если в проектах срочного и необъёмного характера происходит мобилизация старой гвардии и они выполняются споро и с относительно должным качеством, то в средних проектах эта структура начинает пробуксовывать – срываются сроки, проекты мало предсказуемы.
• Вцелом чувствуется нехватка специалистов.
• Загруженность разных специалистов сильно неоднородна.
• Из-за ситуативного (по требованию менеджера) переключения между проектами на само переключение напрасно тратится время, снижается эффективность.
• Низкие взаимозаменяемость и кроссфункциональность – что ведёт к рискам зависимости от конкретного специалиста.
• Из-за предварительного планирования проектов за пределами подразделения, сроки и требования практически “спускаются сверху”, без предварительной проработки трудоёмоксти реализации.
• Некоторые сотрудники выступают сразу в нескольких ролях – Разработчик+Администратор, Архитектор+Разработчик+Аналитик, что мешает эффективности и отнимает время.

В качестве ограничений на возможные рекомендации стоит назвать оторванность рассматриваемого подразделения разработчиков от бизнеса – эта функция выполняется отдельным подразделением менеджеров и аналитиков, которые в основном поставляют скудные требования уровня реализации (”серый ящик”), без должной проработки на уровне бизнес-моделирования и требований уровня “чёрного ящика”.

Я уже некоторое время приглядывался к Agile с целью возможного применения ряда практик и вот наконеч появлилась возможность получить консультацию экспертов.

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

Постепенно были сформированы следующие рекомендации:

Организационные рекомендации

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

Формирование здорового рабочего ритма и команды

• Организация ежедневных “летучек” (scrum’ов) по каждому проекту для синхронизации действий, обмена информацией
• Внедрение регулярных равномерных итераций фиксированной длительности и соответствующих совещаний, с выделением разумных отрезков времени на каждый проект в монопольном режиме (от 3 дней до 2 недель)

Технологические рекомендации

• Достижение полноты позадачного учёта времени выполнения задач с помощью имеющегося инструмента (Jira)
• Использование инструментария автоматизированной сборки (CruiseControl?)

В принципе каждую рекомендацию можно рассматривать отдельно, но это чуть позже.

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

В своём изложении я опираюсь прежде всего на свой опыт, а также на ряд стандартов и методологий, таких как:

• ГОСТ 34.601-90 — Автоматизированные системы. Стадии создания
• RUP — Rational Unified Process
• MSF — Microsoft Solutions Framework
• ГОСТ Р ИСО/МЭК 12207-99 — Информационная технология. Процессы жизненного цикла программных средств

Общий циклический каркас на разных уровнях:

1. Осознание проблемы
2. Исследование и постановка задачи
3. Выработка вариантов решения задачи
4. Выбор варианта решения
5. Реализация решения

Read the rest of this entry »