Допустим есть, какая-то практическая предметная область и реальное предприятие, в нем реальные специалисты предметной области. Допустим, что созрела ситуация, когда лица принимающие решения в этом предприятии начинают понимать, что нужна какая-то автоматизация.
Именно так это формулируется в самом начале. Пройдем по наиболее сложной схеме цепочки развития событий, потому что любое упрощение, будет исключением тех или иных звеньев из этой цепочки.
Следующий порядок действий:
1. Формализовать сформированные специалистами предметной области требования
2. Подобрать решение под требования
3. Формализовать требования на разработку/доработку
4. Формализовать ТЗ
5. Разработать/доработать
6. Интегрировать (внедрить) решение.
7. Техподдержка эксплуатации автоматизированной системы
В таком классическом порядке автоматизации теряется одна из самых важных составляющих современной действительности – НЕОПРЕДЕЛЕННОСТЬ. Т.е. всем известно, что изначально формализованные требования не будут отвечать реальным ожиданиям потребителя, потому что он еще не осознал этих ожиданий, а в процессе реализации его же требований он будет глубже осознавать свои потребности и те возможности, которые ему дает автоматизация. Соответственно и его требования будут изменяться. А в классической проектной цепочке он получит соответствие его первоначальным допроектным требованиям. Решением будет формализовать новые требования и снова проходить проектную цепочку. Это решение неудовлетворительно по причине современной «гонки вооружений» за эффективностью.
Решением кажутся современные принципы проектного управления Agile. В основе принципа Agile лежит возможность изменения требований заказчика в ходе проекта. Казалось бы, решение, но практики современного проектного управления знают, что Agile не является панацеей. Проблема заключается в том, что заказчик изначально настроен платить за результат, который должен быть сформулирован в начале проекта, достигнут и оплачен. Это такая «Правильная» позиция. Убедите заказчика платить за потраченное время, и вы можете пускаться во все тяжкие экстремального Agile. Казалось бы, тоже решение. Да далеко не все заказчики пойдут на такое, но часть согласится, и тогда у них в итоге получится решение, которое будет удовлетворять не их первоначальным требованиям, а их реальным потребностям, которые были осознаны в ходе проекта и явились причиной изменений требований, а соответственно и конечного результата. Стоимость такого проекта будет исчисляться количеством потраченного времени. Чем больше изменений в требованиях, тем больше потраченного времени. Можно хоть 100 раз все переделывать, если заказчик вдруг понял, что ему нужно совсем все по-другому. В чистом виде и эта схема не сработает, потому что проект будет бесконечным, а заказчика будет распирать недоверие. В реальной практике к этому много компаний пришло, но не используя внешних исполнителей они формируют команду исполнителей внутри компании, не осознавая, что их заработная плата и рабочие места, а также время задействованных других сотрудников, является такой же стоимостью проекта. В моей практике руководитель холдинга в 2000 человек административного штата считал 4 млн рублей на проект автоматизации неприемлемыми затратами, в то время как фонд заработной платы 1С разработчиков был 2 млн рублей в месяц. И этот отдел 1С разработки уже три года не мог достичь результатов, которые обозначались в проекте за 4 млн рублей. Это совсем не единичный случай, но вот такие отделы внутренних разработок и есть вариант в своем роде неэффективного Agile. Со своим отделом нет договора, им платится зп, а значит можно в любой момент менять требования. В практике есть много опыта, когда мы договаривались с заказчиком на почасовую оплату по договору, котором определялись общие направления автоматизации и общие результаты, а не четкие требования и ТЗ. Для доверительного исполнения такого договора мы ведем поминутный учет времени, потраченного на конкретные задачи, конкретными исполнителями, с формулировками результатов каждого действия. Это обеспечивает прозрачность, отчасти решает проблему доверия к результатам, но не полностью. Далеко не все заказчики способны понять необходимость тех или иных действий по проекту, оценить правильно эффективность, оценить быстрое решение сложных задач и адекватно отнестись к объективному перерасходу времени по, казалось бы, простым задачам. Все знают некоторые устойчивые методики Agile, которые тут не буду перечислять, у каждой есть свои ограничения.
В какой-то момент мы пришли к выводу, что для каждого проекта существует свой набор обстоятельств, включая и людей, и сами задачи, по которым надо выбирать некий гибридный вариант, который будет работать в этих обстоятельствах, нормально будет восприниматься заказчиком и обеспечит интересы исполнителя, и одновременно приведет к максимально возможному результату. Но такая гибкость в выборе проектных методов тоже далеко не всегда нормально срабатывает, добавляя неопределенности туда, где ее и так хватает.
Суть этой статьи в описании одной мысли, которая только что пришла в голову. До этого момента описывалась лишь ситуация, проблема и попытки ее решения.
Как ни странно, идея лежит в универсализации проектных специалистов. Как вариант в создании универсальных для всех этапов команд.
Пройдем по этапам проектной цепочки с описанием специализации на каждом этапе.
Формализацией требований заказчика занимается бизнес-аналитик. Его задача понять, что хочет заказчик и сформулировать эти требования в понятных для интегратора формах. Интегратор (это тот, кто специализируется на внедрении автоматизации) смотрит, какие готовые решения возможно удовлетворят эти требования, формирует предложения. Если готовые решение не решают поставленные задачи полностью или вовсе нет готовых решений, то интегратор формализует требования на разработку/доработку. Бизнес-аналитики живут в своей среде и зачастую не полностью понимают предметную часть разработки, они могут формулировать требования по бизнес-процессам, но не могут формулировать требования на разработку, а тем более формализовать техническое задание. Конечно, сейчас обсуждается общая масса, со словами, «как правило», на практике существуют специалисты разной степени универсальности. Но нам сейчас нужно именно «как правило». По согласованным требованиям на разработку/доработку должно быть формализовано техническое задание. Формализация, которую хорошо понимают разработчики, по которой они создадут/доработают продукт, который интегратор будет внедрять у заказчика, которому пришло в голову, что что-то в его жизни надо автоматизировать.
В этой гипотетической цепочке выделилось три роли и соответствующие специализации:
1. Бизнес-аналитик. Специализация – бизнес-анализ.
2. Интегратор. Специализация – подбор и внедрение автоматизации.
3. Разработчик. Специализация – разработка систем автоматизации.
А теперь основная мысль. Посмотрите на рынок предложений, каждая компания тяготеет только в одну из трех специализаций. Однажды я спросил у президента одного из крупнейших в России интегратора: «Почему вы не занимаетесь разработкой?», он ответил «Это совсем другая экокультура. Мы пробовали и ничего не получилось». Я наблюдаю на рынке компании и специалистов по бизнес-анализу. Они настолько погружены в свою специализацию с кучей стандартов, нотаций, правил, методов, что не видят конечного результата для заказчика совсем. Их схемы моделей бизнес-процессов, похожие на сложную путину, обычный предметник не может понять. Они должны признать, что забывают, про автоматизацию, занимаясь бизнес моделированием. Разработчики требуют понятного тз и не думают вообще, что получит клиент, для чего вообще это все нужно. Это худший вариант общей картины. На практике в той или иной степени лучше, но полностью вопросы не закрыты.
Универсализация наблюдается в малом бизнеса. Там разработчик может выполнять роль бизнес-аналитика, интегратора и самого разработчика. Или руководитель проекта (интегратор) пытается сам что-то программировать на 1С или C#. Вот бизнес-аналитиков в малом бизнесе не встречал. Но руководители проектов и даже иногда разработчики активно пользуются инструментами бизнес-анализа и нотациями, но кстати делают это гораздо «ближе к народу».
Простая аналогия. В больших городах, в больших больницах врачи являются очень узкоспециализированными специалистами, а в деревнях одному врачу приходится выполнять роль разных специализаций.
Преимущества специализации бесспорны, но надо посмотреть шире на общую задачу автоматизации.
Сама по себе автоматизация без реконструкции бизнес-процессов выглядит как минимум странновато. Разные инструменты разные действия. Реинжиниринг бизнес-процессов без полноценного учета автоматизации как минимум слабо эффективный вариант. Интегратор склонен втюхивать готовые решения, потому что это его зона компетенций, а разработка для него лишние заботы.
От этой несогласованности видимо страдает потребитель.
Решением видится создание очень слаженной команды полного проектного цикла. Тогда роли будут играться немного иначе. Бизнес-анализ будет более глубокий, и на этом этапе заказчик будет уже значительно продвинут в осознании своих реальных потребностей, а значит требования будут более объективными. Интегратор не будет зацикливаться на готовых решениях с доработками в рамках доступных решений своего дилерского пакета (не надо спрашивать у специалиста по 1С на чем лучше автоматизировать бизнес, ответ очевиден). Разработчики будут лучше понимать и подсказывать, как лучше на технологическом уровне, для решения реальных потребностей заказчика.
Как создавать такие команды, как ими управлять, какие проектные методологии использовать, это отдельные вопросы, но определенно видно, что в таком формате проектных команд можно добиться повышения определенности изначально по проекту и отрабатывать в методах близких к классическим, поддерживая эффективность гибких методов Agile.