Архив метки: Analysis

Лучшее будущее и научный подход

Если бы у вас была машина времени и возможность отправиться в прошлое или будущее, куда бы вы отправились? Как это ни удивительно, многие хотят отправиться в прошлое. А ведь там не было горячей воды, современной медицины, интернета и многих других вещей из современного мира, которые делают наш мир таким замечательным!

Michael Specter отправился бы в будущее. И мы с ним полностью солидарны!

Читать далее Лучшее будущее и научный подход

Игра: Успешный проект

Привет, друзья!

А давайте поиграем в симуляционную игру, приближенную к реальности, — вы устроились на работу руководителем проектов в новую для вас компанию. Доставшийся вам проект уже идет. Скажем, прошло уже 30% времени до конечного срока, записанного в контракте. Команда уже набрана и набрана, естественно, не вами. Разработана какая-то архитектура решения и уже даже написан какой-то код, но не весь и там еще кодить и кодить. Заказчик где-то за океаном, очень ждет успех проекта, так как для него это важный имиджевый проект для его бизнеса. Предыдущий менеджер с нашей стороны уходит в другое подразделение на другую должность, объясняя свой уход тем, что «я попробовал и понял — это не мое, не хочу быть PM’ом». Компания его ценит, как толкового специалиста, поэтому нашла для него какую-то позицию в другом отделе.

Как могла сложиться такая стартовая ситуация — не принципиально, ведь у нас же игра, помните? 🙂

Итак, игра началась. Уровень 1й. Поехали!

Читать далее Игра: Успешный проект

Персональная методология проекта

Задаетесь ли вы иногда вопросом, а ту ли методологию я, как руководитель, выбрал для своего проекта? Верной ли дорогой веду проект к успеху?

Насчет успеха — есть очень интересный отчет «Chaos Report» (пока за 2013й год) от известнейшей группы Standish Group о состоянии дел в управлении проектами со списком факторов, приводящих к успеху выполнения проекта и подробным анализом таких факторов с разных сторон и под разными углами. Рекомендую глубоко изучить его на досуге, запланировав для этого как минимум несколько часов в спокойной обстановке. Также ребята из Стратоплана регулярно проводят опрос «Какая методология используется в вашем проекте» и получают очень веселые и показательные результаты. Реальность же такова, что у меня за почти 10 лет управления проектами ни разу не получалось использовать какую-либо методологию в ее каноническом, книжном, классическом виде. Подозреваю, что у вас дела обстоят похожим образом. Всегда есть какие-то обстоятельства, которые заставляют нас из, к примеру, Scrum’а конструировать зверька под названием ScrumBut (Скрам, Но). Про более тяжелые методологии речь даже не идет. Водопад в чистом виде в software development — вообще довольно большая редкость. Периодически встречаю, что на словах он задекларирован, а в реальности по результатам аудита там что угодно, но не водопад.

Расскажу вам одну историю. Руководил я одной программой проектов (группа проектов), где в контракте было указано, что мы работаем с заказчиком по Fixed Price и у нас водопад. Нюанс был в том, что водопад был на каждый релиз, который в свою очередь длился примерно 4-6 месяцев. Такие себе небольшие водопадики, длиной до полугода. Жестокая реальность показала, что если fixed price в такой схеме еще можно сделать прибыльным, то водопад — совсем никак не приживается. Система была настолько сложная, старая, большая, связанная с еще порядка 30 другими системами, ответственная и часто используемая бизнес пользователями заказчика, что изменения приходили пачками каждую неделю. Мы никак не могли заморозить рамки проекта (scope) на срок даже в 1 месяц, не говоря уже про период в 6 месяцев. С другой стороны, более гибкая методология здесь тоже не подходила. Ответственность за корректную и стабильную работу системы настолько высока, а объем кода и модулей внутри системы настолько велик, что никак нельзя обходиться минимумом документации и хаотичной разработкой — дальнейшая поддержка всего этого хозяйства очень скоро стала бы невозможной (почти так и было, когда я пришел в эту программу).

Что же делать? Как управлять проектами, где из-за высокой сложности, объема, ответственности системы перед заказчиком и величины возможных последствий из-за простоя/поломки, требуется водопад (minimum agility), а из-за частых изменений бизнеса у заказчика требуется что-то вроде scrum’а (maximum agility)? И я нашел решение!

Читать далее Персональная методология проекта

Переобучение в IT?

В статье я НЕ буду затрагивать вопросы мотивации и целеполагания, а также крайне важного вопроса «А зачем это делать?». Если уважаемые читатели будут заинтересованы и напишут в комментариях о своем желании увидеть рассмотрение этих нюансов — готов написать продолжение статьи.

Препарировать вопрос подготовки новых специалистов я решил с двух сторон. Со стороны технической и человеческой. Технической стороной назовем некоторые знания предметной области, языка программирования, инструментария и прочие штуки. Человеческой же стороной будем считать качества: способность к постоянному обучению, умение рассуждать, абстрактно мыслить, и, что особенно важно, видеть проблему на нескольких уровнях абстракции одновременно. Джоэль Спольски (в свое время руководил проектом Microsoft Excel, а также автор интереснейшего блога для разработчиков и руководителей) прекрасно осветил обе стороны в своих статьях. В статье «Закон дырявых абстракций» речь идет про техническую сторону. В статье «Опасность обучения на Java» — про качественную.

Читать далее Переобучение в IT?

Теория потерь. Выбор в условиях неопределенности

Самым главным действием любого руководителя является принятие решений. Именно по этой причине он и является руководителем. Но у нас никогда не бывает такой возможности, как принять решение обладая всеми необходимыми нам фактами, обоснованиями и информацией. Мы ВСЕГДА принимаем решения в условиях недостаточности информации. В условиях, когда мы многого не знаем. И все же принимать решения необходимо. В этом наша работа, как профессиональных руководителей.

 

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

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

Чтобы проиллюстрировать несклонность к риску и анализ Бернулли, рассмотрим выбор между проектом, в котором игрок выигрывает $1000 с вероятностью 85% (и с вероятностью в 15% не выигрывает ничего), и альтернативой получения $800 наверняка. Подавляющее большинство людей предпочитают уверенность игре, хотя она имеет более высокий (в математическом выражении) ожидаемый результат. Ожидаемый денежный выигрыш в нашем примере составляет: 0.85*$1000 + 0.15*$0 = $850, который превосходит гарантированный результат в $800. Предпочтение гарантированного выигрыша служит примером проявления несклонности к риску. Вообще говоря, предпочтение гарантированного результата участию в игре с большим или таким же ожидаемым выигрышем называется несклонностью к риску, а отказ от гарантированного результата в пользу игры с равным или даже более низким ожидаемым выигрышем — склонностью к риску.

Читать далее Теория потерь. Выбор в условиях неопределенности