Project management (rus)

Путь

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

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

При выборе определённого жизненного пути вы должны помнить одну штуку: путь в ответ тоже выбирает вас. Или не выбирает… В зависимости от этой взаимности вы потом и будете по нему идти. Если Путь вас не выбрал, то будет это тяжело, мучительно, натужно и, наверняка, с сожалениями потом о том, что вы по нему пошли. А если он выбрал вас, то конечно же будет трудно, но вспоминать потом о нём вы будете с теплом где-то в глубине своей души, если, конечно, не бросите его. Бросить захочется, наверняка; даже путь праздности, роскоши и богатства некоторым надоедает, так что уж о наших аналитческо-тестировочных путях говорить? И Путь будет вам мстить, знайте об этом, если вы его не пройдёте до конца. Если причина покажется ему весомой, то он просто заложит в вашу душу уголёк сожаления, который будет тлеть там всегда, то затухая, то разгораясь, но увы, никогда не погаснет совсем. Путь вас может даже убить. В автомобильной аварии, после очередного дедлайна и пятой ночи без сна.

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

Если рассмотреть это жизненно и с практической точки зрения, вот когда вы делаете демонстрацию заказчику и начинается: “сейчас мы покажем данные о сделке, ой, не, не, не покажем. Сейчас покажем контрагента наверное.” Это что за демонстрация такая с элементами внезапности и неопределённости по середине выверенного процесса? Что это за – “отчёт строится, ой нет бля не строится, это же долго”. Так же и ваш выбранный Путь – ждёт от вас последовательности и логичности.

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

Сразу предвосхищу вопрос – почему именно о нем? Я принципиально не хочу писать здесь о своей семье и их влиянии на меня и мою карьеру. Скажу только, что мой дедушка был офицером ВМФ СССР и он очень любил смотреть фильмы и новостные материалы про флот. Так я и узнал об Александре Сергеевиче Богачеве (а сегодня о нем узнаете и вы) и его имя прочно ассоциируется для меня со словами Долг, Честь и Верность, не из-за красивых слов, а потому что он всегда с достоинством шёл по выбранному им Пути, как и теперь пытаюсь сделать я в банальной и скучной аналитической жизни. То была середина 90-х, самое поганое время, если вы помните, я тогда в школу ходил, но и то немного помню. Никаких ориентиров, никаких моральных принципов – воруй, бей, еби гусей сплошное. Нормальные люди в 1996 уже давно водкой торговали или проститутками вдоль дороги, но никак не в армии на боевом корабле служили.

Если кто помнит фильм на НТВ “Русская акула” про автономный поход подводной лодки – это прям про него. Экипаж буквально умоляли все сходить в эту автономку, так надо было показать всему миру, что России не пиздец, хотя ей тогда пиздец был полный, что вот ребятанавассмотритвсястрана и всё прочее. Догадываюсь, что похрену было стране на них, но Александр Сергеевич принял решение выполнить поставленную задачу, чего бы ему это ни стоило. В той автономке экипаж впервые в истории человечества на планете Земля запустили баллистическую ракету из района Северного Полюса. По возвращении Александра Сергеевича представили к званию Героя Российской Федерации, но звезду получил не он, а начальник штаба флотилии, который выходил с ними на месяц старшим на борту.

Я когда боюсь какого то важного доклада или совещания, всегда думаю об этом – лёд 3 метра, глубина, например, 150 метров. 3 месяца небось нервы как струны гитары, 250 или сколько там жизней от тебя зависит. А я всего на пол миллиона максимум напотрачу. Так как же надо так любить своё дело и верить в свой Путь? Это же не за айфоны и поездки на курорт – они же там зарплату месяцами не получали, на сколько я читал.

В фильме “Русская Акула”, показана его квартира такой, какой она была всегда. Если честно, то мне сейчас и от вида его подъезда уже жутковато. Но он жил кораблём и своим экипажем и мне даже трудно понять тот груз ответственности, который лежал тогда на его плечах, и тот багаж знаний, который был в его голове.

В 1997 году его экипаж дважды стрелял полным боекомплектом ракет с целью их утилизации методом подрыва в воздухе. Я не знаю, понимаете ли вы, насколько это сложная и опасная задача – стрелять из подводного положения баллистическими ракетами, у которых не то что срок эксплуатации, а срок хранения на складах истёк! В интернете эти ролики тоже можно найти, тогда с ними ходили суда сопровождения с американскими наблюдателями на борту. Флагманский ракетчик дивизии Акул (я не моряк, даже часть не назову по памяти), который тоже с ними ходил наблюдателем, рассказывал, что сначала американцы спорили чуть ли не на полуостров Аляска, что ничего не выйдет и только зря погубят людей и корабль, а потом плакали, когда ракеты, одна за одной выходили из-под воды.
– Отчего плакали-то? – спрашивал Командир, – Аляску жалели?
– Нет, Саша! Они плакали и хлопали в ладоши, а потом трясли нам руки и говорили, что это же, блядь, какая гордость быть свидетелями такого подвига, доблести, отваги, выучки и умения русских моряков! Вы же герои, Саша, понимаешь? Ты же герой, Саша! Я, блядь, уверен!

Александра Сергеевича, который осуществил два таких пуска и сэкономил стране сумму денег, равную хрензнаетсколько долларов США минимум, представили второй раз к званию Героя РФ. И все были уверены, что уж сейчас-то точно дадут, ну! Но не дали. Дали орден “За Заслуги перед Отечеством” 4 степени. Поправьте меня, если я ошибаюсь, но даже у Пугачёвой с Леонтьевым ордена высшей степени, чем у Александра Сергеевича.

Но и это его не сломало! Он же не за награды служил, а потому что это был его Путь, который он сам выбрал.

Атомная подлодка к 2005 уже стояла на мёртвом приколе (а я уже учился в университете), а в 2013 у него обнаружили злокачественную опухоль, её удалили, и он проходил курсы химиотерапии, но потом у него обнаружили тромб, удалили его. Лечение требовало корректировки и консультаций с зарубежными врачами, так что собирали ему деньги в интернете всем миром, кто сколько мог на лечение в Израиле. 15 февраля 2015 года Александр Сергеевич ушёл из жизни не дожив даже до 60 лет.

Это был Командир самого ходового корабля 941 проекта (самая большая подлодка в мире высотой с 9-этажный дом и два футбольных поля в длину, внесена в книгу рекордов Гинесса), который первый в мире стрельнул ракетой с восемьдесят восьмой широты и которому, на секундочку задумайтесь, принадлежит мировой рекорд по количеству осуществлённых пусков баллистических ракет.Он не заработал ни денег, ни славы, ни сытой жизни, ни здоровья, но пример, который он показал тогда, пример Человека, верного своему выбранному Пути, я думаю дорогого стоит.

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

К чему всё это написал? Просто меня часто спрашивают – зачем я делюсь опытом, помогаю другим, занимаюсь благотворительностью и т.д. Так вот, я просто выбрал свой скромный (крайне скромный на фоне описанного выше) жизненный Путь Аналитика и стараюсь пройти по нему как можно более достойно, по мере моих сил и возможностей.

Advertisements
Standard
Project management (rus)

Статья “Использование системы управления требованиями Devprom в проектах заказной разработки по ГОСТ”

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

Традиционный скрин:

kiselev storonkin softwarepeople

Standard
Project management (rus)

Big Data Analytics for dummies

Прочитал “Big Data Analytics for dummies”, эту книгу позволяли бесплатно скачать участникам вебинара про Jama Contour. Книга достаточно бестолковая, но в ней всего 55 страниц и поверхностные знания она всё-таки дает (ну или позволяет сориентироваться куда копать). Например, вот пара названий продуктов:

Сама книга выглядит вот так:

Снимок

Standard
Project management (rus)

Поставка

Чем больше изучаю забугорные практики управления требованиями и проектами – тем интереснее становится. Ну, например – нельзя поручать работу по оценке длительности проекта одному человеку, поручи её и менеджеру, и тим лиду, а потом сравни результат.Кстати, deliverables у нас называют “Поставкой”, так что, весьма вероятно, что вам и читать дальше не требуется.

Итак, первым делом опеределяем:

  • Какова цель проекта?
  • Что заинтересованные лица хотят получить в конце проекта?
  • Какие различные документы должны быть приняты в течении проекта?Цели проекта достигаемы/недостигаемы (в т.ч. можно ли это оценить)?
  • Будет ли проект требовать многоуровневой предварительной работы?

Далее идём по шагам:

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

Ну вот и всё, пока что я ищу дополнительные рекомендации.

Standard
Project management (rus), Requirement management (rus)

Практики продуктовой разработки, которые я хотел бы видеть в заказной

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

Если кратко, то в ней я рассказываю о:

  • Заказной разработке
  • Этапах превращения проекта в продукт, какие при этом есть нюансы
  • Типовых проблемах заказного проекта
  •  Какие практики управления требованиями из продуктовой разработки я хотел бы видетьв  заказной
  • Кратко о методологиях разработки
  • Систематизация требований
  • Благодарности и дополнительный слайд – последствия данного подхода (как вариант их можно трактовать как дополнительные работы)

Итак, вот сама презентация:

И хотелось бы сразу добавить важный комментарий от Натальи Желновой (из SlideShare):

Это какая-то очень частная картина мира. У нас, например, есть постановки задач. И тезис про ‘меньше работы’ (урезание функционала) верен только в той ситуации, когда есть серьезные ограничения проекта по срокам/финансированию. Иначе вполне можно подумать, как сделать так, чтобы заказчику было лучше/удобнее работать с системой. Хотя бы для того, чтобы сохранить клиента на будущее.  Словом, я в очередной раз повторяю уже заезженную мысль: процесс управления требованиями НЕ ЗАВИСИТ от того, заказная это разработка, продуктовая или in-house. Все определяется лишь условиями, в которых мы ведем свои проекты, требованиями к качеству конечного результата (как мы можем заметить, для некоторых продуктовых компаний, успешно впаривающих свой продукт, качество не играет особой роли – и следовательно, необходимости в налаженных процессах там нет), а также волей и профессионализмом команды и ее руководства.

Standard
Project management (rus)

Том ДеМарко. Вальсируя с Медведями

Прочитал. Вероятно, если я был бы менеджером, то впечатлился бы больше. Тем не менее, я считаю, что для аналитика есть ряд интересных моментов, а кроме того – аналитик вполне может участвовать в процессе упралвения рисками. Ведь мы, аналитики, более погружены в проект, в отличие от менеджеров. Я приведу наиболее важные и интересные выдержки, а читать ли книгу или нет – выбор исключительно ваш (пишу с планшета, так что мне тяжеловато набирать много текста), в тексте сохранены ссылки на главы книги.

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

Наиболее важные источники неопределенности:
1. Требования к системе: Что именно должна делать система?
2. Обеспечение стандартов взаимодействия: Как будет система взаимодействовать с людьми-операторами и другими системами того же уровня?
3. Влияние изменяющейся среды: Как во время разработки будут изменяться потребности и цели?
4. Ресурсы: Какие ключевые навыки и знания исполнителей возможно будет (при необходимости) привлечь по мере продвижения работы над проектом?
5. Управление: Хватит ли у руководства таланта, чтобы создать эффективные команды, поддерживать боевой дух, обеспечивать низкую текучесть кадров и координировать сложные комплексы взаимосвязанных задач?
6. Сеть поставок: Будут ли другие участники проекта действовать так, как ожидалось?
7. Политика: Каков может быть результат использования политической силы для навязывания ограничений, несовместимых с успехом проекта?
8. Конфликты: Как различные участники проекта найдут компромисс между своими, зачастую несовместимыми, целями?
9. Инновации: Как уникальные для данного проекта технологии и методы влияют на возможный результат?
10. Масштаб: Как повлияет на осуществление проекта увеличение масштаба работ, если раньше у разработчика не было соответствующего опыта?

Управление рисками по сути представляет собой осуществление следующих шагов, включаемых в проект:
1. Используйте процесс идентификации рисков (подробности в главе 14) для составления перечня рисков, которые грозят вашему проекту
2. Убедитесь, что все главные риски проектирования программного обеспечения (подробности в главе 13) представлены в вашем перечне.
3. Проведите всю указанную предварительную подготовку по каждому из рисков:
• Дайте наименование риску и присвойте ему уникальный номер.
• Проведите мозговой штурм для выявления показателей наступления события риска.
• Оцените влияние наступления риска на стоимость и расписание проекта.
• Оцените вероятность наступления риска.
• Рассчитайте подверженность риску в терминах расписания и бюджета.
• Определите заранее, какие меры придется принять, если и когда событие риска наступит.
• Определите, какие меры для ослабления риска следует принять до наступления риска, чтобы обеспечить осуществимость избранных мер реагирования.
• Включите действия по ослаблению риска в обший план проекта.
• Опишите все детали в специальной форме, шаблон которой приведен в Приложении Б.
4. Укажите возможные риски-катастрофы как исходные допущения проекта. Разработайте схему делегирования управления каждым из таких рисков вышестоящему руководству.
5. Сделайте первый подход к оценке расписания, исходя из предположения, что ни один из рисков не материализуется. Другими словами, ваш первый шаг по оценке состоит в определении «даты с вероятностью нанопроцента», то есть самой ранней из дат, к которой вы можете успеть завершить проект. Это отличается от принятой в отрасли практики тем, что мы предлагаем использовать нанопроцентную дату как входные данные процесса составления расписания, а не как его результат. Определите N, используя какой-нибудь из инструментов параметрической оценки, если у вас он есть, настроенный на самые оптимистичные сценарии.
6. Скачайте RISKOLOGY (см. http://www.pmo.ru/riskology). Введите параметры своего проекта в главную рабочую таблицу. Там же введите все индивидуальные настройки, какие сможете найти, опираясь на имеющиеся у вас записи о предшествующей деятельности вашей компании. Замените как можно больше общеотраслевых, заложенных в имитаторе, данных относительно главных рисков имеющейся у вас достоверной информацией. Добавьте индивидуально настроенные рабочие таблицы для всех второстепенных рисков, которые вы отслеживаете. Проведите моделирование для получения диаграммы риска для вашего проекта, добиваясь пересечения с вашей нанопроцентной датой.
7. Выразите, используя диаграмму риска, все обязательства по проекту, в явном виде показывая неопределенность, связанную с каждой планируемой датой и бюджетом. Вместо того чтобы объяснять концепцию диаграмм риска любому из не самых сообразительных заказчиков, отнеситесь к ней как к моделированию своего проекта, сделайте 500 прогонов, показывая все возможные результаты и сравнительную вероятность каждого.
8. Разработайте иерархическую структуру работ, показывающую все задачи, которые нужны для выполнения проекта. Оцените усилия для выполнения каждой задачи, используя любую схему, которую обычно применяете для этого. Мы собираемся использовать эти оценки несколько менее привычным способом: будут приниматься во внимание только относительные веса усилий для выполнения задач, а не их абсолютные значения. Эти относительные веса будут нужны как входные данные для вычисления показателей ООФ.
9. В начале проекта утвердите договоренности по определению входных и выходных потоков данных. Вам следует иметь полную определенность относительно всех потоков данных, вплоть до самого низкого уровня, в пределах первых 12-15% календарного времени. Рассматривайте это как важное контрольное событие проекта. Не переходите к следующим задачам, пока не пройдено это событие. Помните, что неудача с этим показателем, определяющим все потоки, может оказаться роковым предупреждением.
10. Полностью разработайте план разбиения процесса разработки на части до начала осуществления проекта. Используйте это как входные данные для процесса создания плана инкрементных поставок.
11. Когда план разбиения процесса разработки на части завершен, вернитесь к иерархической структуре работ, оцените заново веса задач и выразите задачи в процентах от работы, которую предстоит выполнить.
12. Оцените выгоды с той же точностью, что и затраты.
13. Разбейте требования, содержащиеся в спецификации, до элементарного уровня. Перечислите их в порядке приоритета. В качестве двух критериев установления приоритета выбирайте чистую выгоду для пользователя и технические риски.
14. Разработайте план инкрементных поставок, в котором весь продукт разбит на версии (множество версий, по крайней мере столько, чтобы запланировать появление новой версии примерно раз в неделю). Опишите все требования к элементам соответствующих версий, чтобы пункты с более высоким приоритетом шли раньше. Вычислите ООФ для каждой версии и запишите в план. Рассматривайте план инкрементных поставок как главный результат проекта.
15. Разработайте технологию общих приемных испытаний для данного продукта и разделите их на приемные испытания отдельных версий (ПИn), по одному на каждую версию.
16. Построите график ООФ в соответствии с ожидаемыми датами поставки каждой иерсии. По мере прохождения версиями приемочных испытаний (ПИ) проставьте на том же графике реальные результаты.
17. Отслеживайте на протяжении оставшейся части проекта все риски на предмет наступления или исчезновения и выполняйте планы реагирования всякий раз, когда риски наступают. Наблюдайте за ООФ и его исполнением в сравнении с ожидаемым. Рассматривайте отклонения как признак возможного наступления риска.
18. Поддерживайте в действии процесс идентификации рисков на всем протяжении проекта, чтобы справиться с поздно проявляющимися рисками.

Ниже представлены несколько хитростей, присущих только мозговому штурму в поисках катастроф:
1. Ставьте вопрос в явном виде в терминах ночного кошмара: почему-то это также помогает преодолеть действие неписаных правил, независимо от того, насколько присуще было корпоративной культуре позитивное мышление, ведь по-прежнему считается вполне нормальным вскочить ночью из-за жутких мыслей. Спросите людей, каковы их худшие опасения относительно проекта. Когда они просыпаются в холодном поту от ужаса за проект, что пугает их?
2. Используйте хрустальный шар: Представьте, что у вас есть доступ к хрустальному шару или способность узнавать чудом заголовки газет следующего года. Представьте, что это подглядывание в будущее свидетельствует о бедствии, постигшем проект, но что это за беда? Или, представьте, что ваша компания попала в «колонку идиотов» в журнале The Wall Street Journal, которая располагается посредине первой страницы, а причиной стали бы ужасы, которые творятся с этим проектом. Теперь задайтесь вопросом: «Как это могло случиться?»
3. Опишите противоположные виды на будущее: Попросите людей описать свои самые радужные мечты относительно проекта, а затем обсудите прямо противоположную версию.
4. Спрашивайте о провале, в котором нет виновных: Как может проект потерпеть неудачу без того, чтобы это было чьей-то виной?
5. Спрашивайте о провале, в котором есть конкретные виновники: Спросите людей: «Как бы мог проект провалиться по нашей собственной вине? по вине пользователя? по вине руководства? по вашей вине?» (Это работает, если только убедиться, что все повлечены в действие).
6. Представьте себе частичную неудачу: Спросите, как мог бы проект преуспеть в целом, по оставить одного конкретного участника неудовлетворенным или разгневанным.

Краткий список мер по управлению рисками, которые нужно осуществлять в период с середины проекта и далее, до самого конца:
1. непрерывный мониторинг показателей наступления рисков в поисках такого риска из списка, который кажется готовым перейти из разряда «всего лишь скверной возможности» в разряд «реальных проблем»
2. продолжение выявления рисков
3. сбор данных для наполнения хранилища рисков (базы данных для определения количественного влияния проблем, наблюдавшихся в прошлом)
4. ежедневное отслеживание показателей завершенности (см. ниже)
 
Когда управление рисками действительно ведется и укореняется в корпоративной культуре, проекты смогут пройти все или большинство следующих проверок:
1. Имеется перечень рисков. В этот перечень включены все главные риски проектов разработки программного обеспечения, а также риски, присущие исключительно данному проекту. Риски эти по природе своей причинные (то, что вызовет ужасные результаты, а не то, что само является ужасным результатом).
2. Имеется действующий процесс идентификации рисков. Идентификация рисков ведется открыто, причем приветствуется участие каждого в этом процессе. Конкретные шаги сделаны для того, чтобы можно было безопасно высказывать вслух неприятные вещи. Можно даже открыть анонимный канал для сообщения плохих новостей. Такая схема успешно работает в компаниях некоторых наших клиентов. (Ее не часто используют, но когда используют, это неоценимо).
3. Везде есть диаграммы неопределенности. Их используют для количественного измерения причинных рисков и для выражения совокупных рисков и ожиданий. Корпоративная культура начинает считать непрофессиональным взятие обязательств без упоминания в явном виде об их неопределенности.
4. Имеются цели и оценки проекта, и они никогда не совпадают. Цели могут быть на уровне «нанопроцентной даты» или рядом с ней, а оценки должны быть гораздо более консервативными. Если целью данного проекта является поставка продукта через 12 месяцев, то оценка должна планировать поставку хотя бы месяцев через восемнадцать. В любом случае, конкретный уровень доверия, который связан с любым обстоятельством, должен быть указан диаграммой неопределенности.
5. У каждого риска есть установленный индикатор наступления. Происходит постоянный мониторинг для обнаружения наступления риска.
6. Для каждого риска существует план реагирования и план ослабления. Действия по реагированию на риски включены в иерархическую структуру работ в качестве возможных действий. Действия по ослаблению риска включены в ИСР в качестве необходимых и своевременно осуществляются прежде, чем может возникнуть самая ранняя необходимость ввести в действие план реагирования.
7. Оценивается подверженность каждому из рисков.
8. Существуют количественные оценки выгоды по проекту. После завершения проекта обязательно измеряется реализованная выгода. Имеется упорядоченная по их выгодности (ценности) система компонентов создаваемой системы, используемая как входные данные при планировании версий.
9. В план проекта хотя бы частично встроен инкрементный метод. Некоторые или все версии действительно поставляются заказчикам или происходит псевдопоставка (представляющая собой все необходимые этапы, кроме реальной поставки). Данные о времени, усилиях и т.п. обрабатываются по каждой завершенной версии и используются в качестве показателей завершения во второй половине проекта.

Standard
Project management (rus)

Про планирование

Кстати, прочитав “Роман об управлении проектом” не могу не вспомнить об одной истории. Знавал я одну компанию (он до сих пор весьма успешно работает на рынке), в которой перед тем, как поставить задачу в разработку – она детально прорабатывалась аналитиками. Причем, сначала над ней успевали поработать и бизнес-аналитики и системные, и архитекторы, и, даже разработчики (оценка реализуемости). Кроме того, при возникновении нескольких вариантов решения в компании организовывались отдельные комитеты (или рабочие группы, но все это ыло крайне оперативно), а решение тщательно фиксировалось ля будущих поколений.
Так вот, одну из систем очень скурпулезно прорабатывали  теении 7 месяцев, в итоге была и архитектура БД, и проработанны интерфейсы (с описанием всех возможных взаимозависимостей и проверок), только вот незадача – проект так и не стартовал. На него не нашлось разработчиков, так как все работали на другом, очень критичном для компании проекте. Стартовал ил в итоге проект или нет – я не в курсе, но более чем пол года вся документация “пылилась на жестких дисках”. К ему я это? А к тому, что не смотр на все те замечательные вещи о полной проработке системы до начала её реализации не следует забывать про риски. То, что все разработчики загружены, руководство, на мой взгляд, не могло не знать, но проект тем не менее прорабатывался.
На этом я продолжаю читать книгу “Вальсируя с медведями”.

Standard