Поговорим о рисках

Что такое риски? Что является риском, а что нет? Как учитывать риски при оценке трудоёмкости ПО и планировании проекта? Об этом я предлагаю поговорить в этом топике. В то же время, чтобы не раздувать топик и не повторяться, здесь не будут обсуждаться вопросы идентификации и митигации рисков — действий по выявлению, уменьшению вероятности возникновения рисков и минимизации их последствий.
После публикации статьи о смертных грехах в оценке трудоёмкости программного обеспечения мне указали, что ни автор, ни я ничего не сказали о рисках. Хочу исправить это досадное недоразумение и поведать вам немного о рисках и моём опыте работы с ними.

Друзья, не знаю как вы, но мы не верим в быстродействующие таблетки. Мы не верим в «похудение за 2 недели на 40 кг». Черт побери, верить-то хочется, но реальность обычно против…

А тут целый PMBoK… Здоровенная такая штуковина, для больших и умных корпораций, а также неповоротливых гос.заказчиков… Как оказалось все не совсем. Для того, чтобы рассказать о чем-то сложном в понятной и доступной форме нужен практик, который разобрал вопрос до деталей, выделил главное, расставил акценты и прошелся по материалы с большим ярким маркером – читать тут, смотреть тут, применять вот так.

4 года назад менеджер по управлению проектами (PMI PMP), автор книги «Управление ИТ-проектом с нуля в любой организации» Иван Селиховкин выпустил бесплатный курс «Практический PMBoK за 5 дней», который на сегодня уже скачало более 7.000 человек. Однако, не так давно Иван пошел дальше и выпустил курс «Практический PMBoK за 2.5 часа» (доступен бесплатно после регистрации).

5 дней — я еще понимаю, но 2.5 часа — как-то того… отдает похуданием за 40 минут. :) Поскольку мы с Иваном давно сотрудничаем, то решили выяснить, как так получилось, что курс ужался с 5 дней до 2.5 часов. И начав говорить, поняли, что надо делать отдельное интервью. В итоге, обсудили массу тем:

• Как из медицины попасть в управление IT-проектами
• Почему последние годы процент успешных проектов не меняется
• Три шага на пути создания проектного офиса
• Что такое гос.заказчики геройские, бизнесовые и заурядные
• Есть ли противоречие между PMI и гибкими методологиями
• …

Естественным путем завершился опрос «Какая методология используется в вашем проекте». На текущий момент ответили 2,668 человек — огромное всем спасибо!

Удивительным образом снова победили “Через %опу” и “Как получится”: 58% в сумме. На выходных, когда лидеры уже определились, мы сели обсуждать эту ситуацию с нашим экспертом по управлению проектами Иваном Селиховкиным.

По ходу разговора Иван поделился интереснейшим концептом про патологические матрицы проекта, после чего мы а) заствили Ивана зарегистрироваться на Хабре (встречайте: selikhovkin) и б) решили записать отдельное видео про эти самые матрицы:



35 минут о том, что бывает не так в проектах — пять часто встречаемых шаблонов:

• Гипер-ТОП
• Нервный ПМ
• Расстрельный ПМ
• ПМ-ТОП
• Ненужный ПМ

А под катом — сводная таблица по методологиям с 2009 года

Не так давно мы проводили опрос по проблемам в проектах для нашей новой программы “Формула управления проектами”. Получили более 600 ответов, которые распределились в темы работы с заказчиком, оценок работ, сроков, коммуникаций и прочих безусловно нужных проектных вещей.

Интересным оказался эмоциональный настрой многих комментариев. Возникло четкое ощущение, что многие коллеги недовольны своей действительностью. Но при этом не знают, как ее изменить в лучшую сторону — и крайне недовольны этим. Отчего текущая действительность описывается достаточно красочными эпитетами. Эту же картину косвенно подтвердил и недавний опрос по методологиям.

Мы пригласили в студию нашего эксперта по управлению проектами Ивана Селиховкина (selikhovkin) и попросили поделиться историей наведения порядка. В итоге Иван рассказал историю о том, как он с коллегами по шагам за 90 дней привел компанию от хаоса к работающему проектному офису. Находясь при этом не на должности ТОП-менеджера. Все изменения шли СНИЗУ.



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

Если это видео придаст правильный заряд, будем категорически рады. Хороших выходных!

P.S. Если поможете нам с опросом по проблемам проектов — будем отдельно благодарны.

P.P.S. Краткое содержание истории по шагам — под катом:

Друзья, спасибо за позитивные комментарии после нашего последнего видео «Как навести порядок снизу: за 90 дней от бардака к проектному офису»! Мы решили продолжить разговор с нашим экспертом по управлению проектами Иваном Селиховкиным (selikhovkin). И затронули такую холиварную тему, как знания и навыки, которыми должен обладать хороший ПМ.

Я отчетливо помню, как после пары лет работы в Intel у меня возникло четкое убеждение, что я знаю, как надо. Убеждение было вскоре многократно пересмотрено после работы с аутсорсинговыми компаниями (о, сколько там многообразия!), стартапами, ИТ-отделами не-ИТ компаний и т.д.

Расширение контекста (не важно, инженера или менеджера) – чертовски важная штуковина. Поэтому помимо набивания собственных шишек, мне всегда было интересно разговаривать с людьми, имеющими разносторонний опыт и широкий кругозор. selikhovkin – безусловно, один из них. Как человек системный, Иван набросал еще и интеллект-карту «Знания и навыки хорошего менеджера проекта», по которой и вел рассказ.

На одной из конференций произошел комичный случай. Подходит слушательница:

— Александр, есть такой вопрос: Как нам повысить уровень доверия в отношениях с заказчиком?

— А что сейчас не так с уровнем доверия?

— Ну, у нас есть команда, есть менеджер. И мы хотим, чтобы заказчик доверял команде и общался только с менеджером. А он лезет напрямую к инженерам…

— А чем это плохо? Человек сразу получает ответы на свои вопросы, быстрые коммуникации и все такое.

— Понимаете… Мы ему джуниор инженеров продаем как синьор инженеров… И нам не хотелось бы, чтобы он обнаружил этот факт.

Напомню изначальную постановку вопроса: “Как нам повысить уровень доверия в отношениях с заказчиком?”

Вот о заказчиках сегодня и поговорим. А точнее, о простом инструменте, который:

• Поможет осознать, где находятся ваши отношения с заказчиком
• Покажет, почему формы отчетов иногда бывают такие идиотские
• Возможно, поможет понять причины “неадекватного” поведения заказчика

После прошедшего PM-Weekend удалось поймать selikhovkin и попросить записать несколько видео по самым популярным вопросам про управление проектами. Сегодня — первое видео:

10 ответов на вопросы про работу с заказчиком

В рамках видео Иван тезисно раскрыл следующие вопросы:

1. Как заинтересовать бизнес в повышении зрелости системы управления?
2. Методы по формированию ожиданий у заказчика по проекту и их использование
3. Как понять, что хочет заказчик?
4. Как удерживать заказчика от раздувания требований?
5. Как научить заказчика доверять разработчику?
6. Какие методики/методологии ведения проектов и общения с заказчиком существуют?
7. Саботаж сотрудников заказчика (как бороться)?
8. Как сообщить заказчику, что проект идет не по плану, какие фразы использовать, как сгладить впечатление?
9. Особенности работы с гос.заказчиками
10. Что делать менеджеру на проекте, который заказчик пускает на самотек?

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



Чем планирование софтверных проектов похоже на написание книги, как гуры экспертного управления планировали бы написание продолжения “Войны и мира”, и что такое метод оценки трех П — обо всем этом в новом видео.

“Да потому что я постоянно этим занимаюсь” — Иван Селиховкин (selikhovkin) в ответ на вопрос, почему мы будем записывать видео именно на эту тему.

После публикации бесплатного курса “Практический PMBoK за 2.5 часа” мы получили массу вопросов про конкретику от тех, кто курс посмотрел, и немало вопросов-сомнений от тех, кто курс не смотрел и вообще сомневается, что курс на 2.5 часа может содержать что-то полезное.

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

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



7 последовательных шагов, которые должен пройти менеджер от своего “медового месяца” к выводам о том, что делать с проектом дальше.

Всем привет!

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

Эффективное планирование зависит от множества разных факторов: от качества оценки, проработки деталей решения, использованной методики планирования, правильной оценки рисков.

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

Если вы не знаете, в каком направлении развивать проект, то он вряд ли выберет нужный путь самостоятельно.
Стив Макконнелл

Введение

В предыдущей статье «Обзор процесса разработки программного обеспечения» [1] я рассказал о самом «верхнем уровне» процесса разработки, сложившегося в моей практике на текущий момент. Во введении к «Обзору» я постарался сформулировать используемые термины и привёл примеры некоторых проектов, в которых использовался рассматриваемый процесс.

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

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

Для достижения поставленных целей заказчику и исполнителю совместно нужно решить ряд вполне определённых задач:

1. На основе исходной идеи сформулировать цели и задачи будущего проекта.
2. Разработать некоторое исходное видение – концепцию проекта.
3. Провести анализ востребованности будущего продукта.
4. Провести предварительную оценку рисков будущего проекта.
5. На основе концепции и списка предварительных рисков подготовить предварительное техническое решение.
6. Выбрать методологию разработки и подготовить предварительный план работ.
7. Провести предварительную оценку трудозатрат и необходимых ресурсов.
8. Провести анализ реализуемости продукта.
9. Провести независимое рецензирование технического решения.
10. Принять решение о том, стоит ли продолжать работы.

Это продолжение статьи: Что делать, если нужно создать инновационный продукт в традиционной компании?

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

История №1. «Built it and they will come»

Фермер из Айовы Рей Кинселла в недоумении, так начинается фильм «Поле чудес». Последнее время он постоянно слышит голос, который советует ему построить бейсбольное поле на месте его кукурузных угодий. Кому-то, возможно, такое предложение и показалось бы начисто лишенным смысла. Но не Рею. Ведь его покойный отец когда-то был просто помешан на этой игре. Любящий сын решает последовать совету. И вот поле построено, и на нем появляется призрачная команда легендарных игроков. Рей не столько напуган, сколько озадачен. Чтобы понять смысл удивительных событий, он начинает собственное расследование…То, что слышит герой, это фраза «Built it and they will come».

Это вторая часть из цикла четырех статей о разработке физических продуктов. Если вы пропустили Часть 1: Формирование идеи, обязательно её прочтите. Вскоре вы сможете перейти к Части 3: Конструирование и Части 4: Валидация. Автор: Ben Einstein. Оригинал Перевод выполнен командами фаблаба FABINKA и проекта РУКИ.

Часть 2: Дизайн

Каждый шаг на стадии дизайна – изучение клиента, каркасное моделирование (wireframing, подробнее по-русски), визуальный прототип – нужен для проверки гипотез, как будет выглядеть продукт и как пользователи будут взаимодействовать с ним.


Рисунок 2.1 Этапы дизайна продуктов

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

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



Цель этой статьи заключается в том, чтобы заинтересовать читателей чем-то вроде формального представления знаний в сфере разработки программного обеспечения, продемонстрировав им идею паттернов проектирования и описав несколько паттернов, которые интересны тем, что они нашли применение в современной JavaScript-Разработке.

Многие программисты начали переходить со второй версии Python на третью из-за того, что уже довольно скоро поддержка Python 2 будет прекращена. Автор статьи, перевод которой мы публикуем, отмечает, что основной объём Python 3-кода, который ему доводилось видеть, выглядит как код со скобками, написанный на Python 2. По его словам, он и сам грешит чем-то подобным. Здесь он приводит примеры некоторых замечательных возможностей, доступных лишь тем, кто пользуется Python 3. Он надеется, что эти возможности облегчат жизнь тем, кто о них узнает.



Все примеры, приведённые в этом материале, написаны с использованием Python 3.7. В описании каждой возможности имеются сведения о минимальной версии Python, необходимой для её применения.

Автор материала, перевод которого мы сегодня публикуем, говорит, что C++, в его современном виде, если сравнивать его с тем, чем был этот язык несколько лет назад, значительно изменился в лучшую сторону. Конечно, эти изменения произошли далеко не сразу. Например, в былые времена C++ не хватало динамичности. Непросто было найти человека, который мог бы сказать, что он питает к этому языку нежные чувства. Всё изменилось тогда, когда те, кто отвечает за стандартизацию языка, решили дать ход новшествам. В 2011 году C++ стал динамическим языком, языком, который постоянно развивается и вызывает у программистов куда больше положительных эмоций.

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



Сегодня мы поговорим о некоторых новых возможностях языка (начиная с C++ 11, которому, кстати, уже 8 лет), знать о которых будет полезно любому программисту.

На часах 7:15 утра. Наша техподдержка завалена работой. О нас только что рассказали в передаче «Good Morning America» и множество тех, кто впервые посещает наш сайт, столкнулось с ошибками.

У нас настоящий аврал. Мы, прямо сейчас, до того, как потеряем возможность превратить посетителей ресурса в новых пользователей, собираемся выкатить пакет исправлений. Один из разработчиков кое-что подготовил. Он думает, что это поможет справиться с проблемой. Мы размещаем ссылку на обновлённую версию программы, пока ещё не ушедшей в продакшн, в чат компании, и просим всех её протестировать. Работает!

Наши героические инженеры запускают скрипты для развёртывания систем и через считанные минуты обновление уходит в бой. Внезапно число звонков в техподдержку удваивается. Наше срочное исправление что-то поломало, разработчики хватаются за git blame, а инженеры в это время откатывают систему к предыдущему состоянию.



Автор материала, перевод которого мы сегодня публикуем, полагает, что всего этого можно было бы избежать благодаря TDD.

«Мы начинаем разработку новой игры, и нам нужна классная вода. Такую сможешь?»


, — cпросили меня. «Да не вопрос! Конечно, смогу», — ответил я, но голос предательски задрожал. «А, еще и на Unity?», — и мне стало понятно, что впереди очень много работы.