?

Log in

No account? Create an account
Кроличья нора информационных технологий - Экономика, управление, ИТ, системы, анализ
January 18th, 2015
03:14 am

[Link]

Previous Entry Share Next Entry
Кроличья нора информационных технологий
Вдруг мимо пробежал кролик с красными глазами.
Конечно, ничего удивительного в этом не было. Правда,
Кролик на бегу говорил:
-- Ах, боже мой! Я опаздываю.
Но и это не показалось Алисе особенно странным. (Вспоминая
об этом позже, она подумала, что ей следовало бы удивиться,
однако в тот миг все казалось ей вполне естественным). Но,
когда Кролик вдруг вынул часы из жилетного кармана и, взглянув
на них, помчался дальше, Алиса вскочила на ноги. Ее тут
осенило: ведь никогда раньше она не видела кролика с часами, да
еще с жилетным карманом в придачу! Сгорая от любопытства, она
побежала за ним по полю и только-только успела заметить, что он
юркнул в нору под изгородью.
В тот же миг Алиса юркнула за ним следом, не думая о том,
как же она будет выбираться обратно.
Нора сначала шла прямо, ровная, как туннель, а потом  вдруг
круто  обрывалась  вниз. Не успела Алиса и глазом моргнуть, как
она начала падать, словно в глубокий колодец.
(с) Льюис Кэррол, Приключения Алисы в стране чудес


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

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

Если коротко - это неопределенность в трех главных, но взаимосвязанных вопросах:
1. каков класс предмета поставки данного проекта/работы?
2. что является основной (базовой) создаваемой/планируемой системой?
3. в каких точках жизненного цикла предмета поставки и базовой системы мы сейчас находимся?

Эти вопросы не ставятся и не отвечаются по разным причинам:
- кто-то не знает, что их надо ставить;
- кто-то не знает на них ответы в данной ситуации;
- кто-то умышленно скрывает.

В итоге, как и во многих играх с неопределенностью в сроках, бюджетах и ресурсах, ситуация приобретает мистические свойства для укрощения которых требуется Лидер с большой буквы "Л" и множество его лидерских качеств.
А вот и он: менеджер с глазами, красными от кофе, прибегает к аналитикам с воплями: "боже мой, как я опаздываю! Герцогиня отрежет нам голову!". И стремительно увлекает нас вглубь проекта да так, что выход из него без потерь становится проблематичным.

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

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

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

Вот здесь (http://boatmanshome.ru/wiki/wacko/?page=AvtomatizirovannyeSistemy&v=tif) все написано более детально, а сейчас коротко.

[Ликбез...]Класс предмета поставки

Всего мы можем рассматривать несколько видов базовых систем в контексте которых пишется любой код:
- автоматизированная система: люди, железо и софт, вместе выполняющие полезную работу;
- автоматизированный сервис: люди, железо и софт, вместе предоставляющие оговоренную услугу;
- автоматизированный бизнес-процесс(ы): люди, железо и софт, вместе реализующие заданную цепочку прибавленной стоимости.
- скажите мне, что я забыл?

И есть несколько видов возможных предметов поставки ИТ проекта:
- автоматизированная система/сервис/процесс (дальше я буду упоминать лишь автоматизированую систему, так как все, что будет ниже сказано о ней равно относится и к сервису и к процессу);
- информационная система (железо+софт+информация);
- обеспечение информационной системы - то самое железо, программное обеспечение, информационные изделия (и еще ряд менее упоминаемых вещей):
- программный продукт, как унифицированный компонент программного обеспечения.

Можно видеть, что классы продуктов взаимосвязаны: информационная система является частью автоматиизрованной, а программное обеспечение яляется частью информационой системы.
В соответствии с этим и объемы (и бюджеты, и сроки) проектов при подмене класса предмета поставки будут расти и уменьшаться (и эта разница может достигать пары порядков).

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


Жизненные циклы

Для автоматизированной системы выделены стадии ее жизненного цикла:
1. Требования заказчика - здесь определяются границы автоматизируемой деятельности и задаются улучшаемые показатели, оценка бюджета и сроков возможна по аналогии, точность - порядок-два;
2. Концепция - здесь принимаются проектные решения, существенно снижающие неопределенность в оценке, чаще всего путем декомпозиции системы в разных плоскостях и создания укрупненного плана работ, оценка бюджета и сроков возможна с точностью до полупорядка (часто прорабатываются варианты и предоставляются исходные данные для выбора, например, в виде ТЭО);
3. Техническое задание - планирование и контрактирование, определяются исполнители и окончательные базовые технологии, что снижает неопределенность оценки, остальная неопределенность распределяется между участниками в виде рисков и буферов по времени и деньгам. Все встают на деньги и сроки.

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

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


5 и далее пока не интересно.


Если кому-то не нравится ГОСТ, все тоже можно переложить и в другие термины:
1. Бизнес-процессы и/или описание предметной области
2. Бизнес-требования (и/или vision)
3. Управленческие документы: роадмап, план работ, бюджет тут идут чуть сбоку в силу различия управленческих традиций.
4. Системные требования.
5. и т.д.





Основное, что важно осознать:
1. стадии 1 и 2 (в любом из двух списков) снижают неопределенность с 1-2 порядков (х10..100) до полупорядка (х3..4).
2. дальнейшее снижение неопределенности возможно только с участием разработчиков, так как их внутренняя неопределенность начинает как конкурировать, так и вступать в сложное взаимодействие с неопределенностью в проектных решениях по системе.
3. Количество бумаги (и бюжет на аналитиков) растет с каждой стадией (кроме 3-ей) приблизительно на порядок-полпорядка, то есть экспоненциально.
4. Качественные аналитические работы на стадиях 1 и 2 удельно дороже (выше требуемая квалификация аналитиков) раза в 2, чем на стадии 4.

Так вот о белом пятне
Часто написанные выше вещи никто не принимает в расчет, слепляя стадии 1-4 в один большой ком, что иногда оправданно, а иногда дает проекту летальную дозу исходной неопределенности.
Заявки на тему: "мы хотим получить требования в качестве исчерпывающего входа для разработчиков", я получаю по паре раз в месяц. Там часто нет никаких решений по системе кроме ее названия и, возможно, бюджета, но это секрет (о том, кто будет разрабатывать, скорбно умолчим).

Всем кажется, что это проблемы лишь аналитиков в то время, когда у аналитиков есть 3 исхода в такой ситуации:
1. Перезаклад по срокам и бюджету аналитических работ - заказчик проигрывает и по срокам старта разработки и по деньгам. Но хуже, когда оцнка превышает ожидания заказчика по бюджету и он вообще отказывается или от проекта в целом (хотя может он был проходной) или от аналитических работ (что не добавляет в проект определенности).
2. Занижение качества аналитических артефактов и/или срыв сроков аналитических работ - проигрывает и заказчик и команда: команда лишнее время стоит под холостыми оборотами (кто-то берет на себя эти расходы), команда получает плохой вход, заказчик получает плохой выход.
3. Чудом оценка совпала с действительностью.

Даже при подсчете методом встречу/не встечу динозавра. Вероятность чуда = 1/3. Это очень близко к мировой статистике успешности ИТ проектов ;)

Давайте считать, чем грозят скомканные стадии 1-2 или сразу 1-4

Доля аналитических работ в смете колеблется от 5-10% (заказная разработка) до 25-30% (кастомизация платформы).

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

Допустим, в другом проекте снижение неопределенности от стадии к стадии невелико (х3), количество бумаги растет не сильно (x3), а доля аналитических работ велика (30%). Тогда, заказывая аналитические работы, Лидер на стадиях
1. Платит аналитикам 1х2 денег, снижаяя неопределенность в 3 раза;
2. Платит аналитикам 3х2 денег, снижаяя неопределенность в 3 раза;
4. Платит аналитикам, 9 денег, задавая исчерпывающий вход на кастомизацию.

Предельный перезаклад бюджета = х9.
Переплата за аналитические работы первых двух стадий = 8 денег или 47% от аналитического бюджета, или 14% от полного бюджета.
Каалось бы, выбор очевиден.

Но важно понимать, что вероятность предельного перезаклада х9 ничтожно мала, в реальности средний перезаклад не превышает 4 с копейками (легко проверяется в экселе).
И наш красноглазый собрат стоит перед выбором:
- заплатить конкретные 14% бюджета проекта за неясные бумаги в неустановленном качестве (а будем откровенны, не все у нас после сдачи документации по ГОСТ на вес умеют быстро перестраиваться на четкие и ясные аналитические документы)
- или перевесить риски на команду разработки которая
-- во-первых все равно умножит свою смету на 3,1415 (а чтобы квалифицированно спорить с ними надо разбираться в архитектуре и разработке), а
-- во-вторых всегда может бегать на 50-100% быстрее, если правильно кошмарить. Например, перевести на scrum process.

Решение очевидно и сегодня его принято считать гениальным менеджерским ходом.

Чуть позже этот гениальный ход копируется в проект, где аналитические работы могли бы снижать неопределенность на стадиях 1 и 2 гораздо сильнее. Или просто путается класс продукта и требования, например, к программному продукту собираются вне контекста решений базовой системы (их просто может не быть). И вышеописанная арифметика резко перестает работать.
Лидер  все еще пытается устраивать "Алису в стране чудес", пока не получает сакраментальное: "Кому вы страшны? Вы ведь всего-навсего колода карт!".

С другой стороны есть и другая арифметика.

Если мы знаем ориентиры по бюджету, а мы их знаем всегда (хоть и не всем рассказываем). Вот здесь (http://boatmanshome.ru/wiki/wacko/?page=Zametki/GlavnajaProblemaITProekta&v=u4m) я приводил естественные экономические ограничения бюджета.

Так вот, зная бюджет надо понимать, что потратив 1-3% (максимум 5%) этого бюджета мы сможем избавить проект от очень неприятной неопределенности и рисков на входе, отсрочив глобальные решения на 10-20% от полного срока внедрения (на первых фазах команда меньше, по этому отсрочка не пропорциональна стоимости стадий). Для кастомизируемых систем такая отсрочка может достигать 30-40% от срока внедрения.
Минус в том, что есть реальные шансы этот бюджет снизить, а кто в этом зинтересован, скажите мне честно?
Но что еще страшнее, такие проволочки по срокам часто отпугивают Лидеров с большой буквы "Л", ведь подобное промедление может выставить их слабаками в глазах начальства.
Если бы два автобуса разработчиков все это время копали бы яму, мы бы уже получили 10-40% видимого прогресса, выраженного в твердых строках кода. А из аналитических работ выпадают лишь какие-то бумаги, качество и пользу которых донести до начальства бывет очень трудно.

Есть еще много разных случаев, которые не поместились в эту заметку.

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

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

В остальных случаях нет объективного повода усложнять себе жизнь. При всей любви к творчеству прекрасного Льюиса Кэролла, давайте не забывать, что он на самом деле был Чарльз Лютвидж До́джсон, большой шутник и математик, основные достижения, оставивший в области логики.

Tags: ,

(6 comments | Leave a comment)

Comments
 
[User Picture]
From:Igor Makarov
Date:January 19th, 2015 11:11 am (UTC)
(Link)
Всё это понятно и известно (в теории и на совбственных шишках).
Но изначальная излишне высокая ставка на этап аналитики надолго откладывает откровения заказчика, когда ему показываешь MVP. И тогда он вдруг понимает, чего на самом деле ему хотелось.
[User Picture]
From:darkboatman
Date:January 19th, 2015 07:08 pm (UTC)
(Link)
Ну сейчас я обычено предлагаю разбить на 2 части: короткое уточнение рамок и объема системы - несколько часов работы, затем может появиться более взвешенная оценка и приоритеты - где копаем, а где не нужно. Я к тому, что часто входная неопределенность и отсутствие приоритетов и различной деетализации по элементам объема системы раздувает оценку аналитических работ.
[User Picture]
From:francugzenka
Date:September 4th, 2015 12:31 pm (UTC)
(Link)
Yj gjxtve ;t ns gthtcnfk cjxbyznm cnb[b!!!!! D hbavt nfr vyjuj hbnvf//////
[User Picture]
From:darkboatman
Date:September 8th, 2015 08:31 pm (UTC)
(Link)
wtf?
[User Picture]
From:francugzenka
Date:September 14th, 2015 11:50 pm (UTC)
(Link)
транслит) - Но почему же ты перестал сочинять стихи!!!!! В рифме так много ритма//////
[User Picture]
From:darkboatman
Date:September 15th, 2015 05:36 am (UTC)
(Link)
Кто сказал, что перестал? ;)
Boatman's Home Powered by LiveJournal.com