Уголок

Процесс vs Результат

2010-06-02T08:51:00.000-07:00

Одни говорят, что менеджмент - это Процесс...
Другие говорят, что менеджмент - это Результат...
Я думаю, менеджмент - это и Процесс и Результат.
Процесс без Результата не имеет смысла.
Результат без Процесса невозможен.

Чуть больше об этих понятиях в книге Масааки Имаи "Кайдзен. Ключ к успеху японских компаний"

«…Ключевое различие в понимании изменений в Японии и на Западе заключается в концепции кайдзен, принципы которой для многих японских менеджеров столь естественны и само собой разумеются, что они применяют их, не отдавая себе в этом отчета. Понятие кайдзен объясняет, почему компании в Японии не могут долго оставаться неизменными. После долгих лет изучения западной практики ведения бизнеса я пришел к выводу, что концепция кайдзен сегодня не существует или выражена весьма слабо в большинстве западных компаний. И, что еще хуже, они отвергают ее, не имея ни малейшего понятия об ее принципах. Берет свое старый синдром «у нас это не приживется». Именно отсутствием кайдзен объясняется, почему американский или европейский завод может совершенно не меняться в течение четверти века.
Сущность кайдзен очень проста: совершенствование. Более того, это непрерывный процесс совершенствования, в котором участвуют все — и менеджеры, и рабочие. Философия кайдзен предполагает, что наш образ жизни, будь то работа, общественная или семейная жизнь, заслуживает постоянного улучшения…
…Кайдзен порождает мышление, ориентированное на процесс, поскольку, чтобы получить более высокие результаты, надо сначала улучшить процесс. Более того, кайдзен рассчитан на человека и на усилия, предпринимаемые людьми. Это резко контрастирует с мышлением большинства западных менеджеров, ориентированным на результат.
По словам Маюми Оцубо, менеджера по проведению соревнований и рекламных акций в Bridgestone Tire Co, Япония — это общество, ориентированное на процесс, в то время как США — общество, ориентированное на результат. Так, оценивая показатели сотрудников фирмы, японский менеджер уделяет особое внимание отношению человека к работе. Если менеджер по продажам анализирует показатели продавцов, его оценка обязательно включает такие ориентированные на процесс критерии, как время, затраченное на привлечение новых клиентов; время, использованное на телефонные звонки клиентам по сравнению со временем, в течение которого продавцы занимались канцелярской работой в офисе; процент новых контактов, завершившихся заключением сделки. Принимая во внимание эти показатели, менеджер по продажам заботится о том, чтобы его сотрудник рано или поздно улучшил результаты работы. Иными словами, считается, что процесс не менее важен, чем совершенно конкретный намеченный результат — объем продаж!
В США, как правило, не имеет значения, насколько усердно работает сотрудник. Отсутствие высоких показателей неизменно ведет к низкой оценке его труда и низкому доходу или статусу. Личный вклад оценивается только по конкретному результату. В обществе, ориентированном на результат, засчитывается только результат."

Менеджмент, ориентированный на Процесс носит долгосрочный стратегический характер.
Менеджмент, ориентированный на Результат решает сиюминутные задачи.

Ключевые показатели менеджмента, направленного на Процесс:

дисциплина;
управление временем;
развитие навыков;
соучастие и вовлеченность;
мораль;
коммуникации и т.д.

Ключевые показатели менеджмента, направленного на Результат:

количество строк кода;
количество дефектов;
количество реализованных бизнес-процессов и т.д.

Ключ к успеху - это баланс между этими двумя типами управления.

Почему 9 женщин не могут родить ребёнка за 1 месяц или О применении имитационного моделирования в управлении проектами

2010-03-29T02:08:00.000-07:00

Введение

Думаю, многие из вас слышали выражение "9 женщин не могут родить ребёнка за 1 месяц!". Контекст этого выражения очевиден - в разработке ПО его применяют в качестве аллегории, когда протестуют против совершенно неприемлемого сжатия сроков. Здесь под сжатием понимают сокращение сроков разработки путём расширения команды при сохранении общей трудоёмкости разработки.

Совершенно очевидно, что сжимать сроки до бесконечности невозможно. Существует определённый предел. Например, известным экспертом в области оценки трудоёмкости разработки ПО Стивом Макконнеллом (Steve McConnell) этот порог определён как 25% от исходных оценок (см. мою предыдущую статью).
Но этот топик не об оценках трудоёмкости...
Вот я выше написал "совершенно очевидно...". Думаете, это действительно очевидно? Всем?
Мой недавний опыт показал, что это очевидно далеко не всем. Проект был очень крупный и срок сдачи неумолимо приближался. Было принято решение резко расширять команду, чтобы успеть. Довод про "9 женщин" никто не принял. Команда была расширена и в срок мы всё равно не успели. Можно ли было как-то, кроме как на словах, показать, как будут развиваться события? Вот о том, как смоделировать такую ситуацию, и будет моя статья.

Уверен, что многим из вас приходилось принимать какие-то решения, от которых впоследствии зависело очень многое. Как вы их принимали? Чем руководствовались? Знали ли вы наверняка, как именно будут развиваться события в зависимости от того, какой выбор был сделан? А ведь чем выше должность в иерархии управления, тем дальновидней должны быть решения и тем дороже обходятся ошибки от неверно принятых решений.

В большинстве случаев решения принимаются интуитивно, на основе жизненного и профессионального опыта. Принимая решения, на подсознательном уровне мы учитываем множество факторов, учитываем те знания, которые получили ранее. Только вот что, если вам нужно кому-то объяснить, почему вы так уверены в своём решении? Тут, конечно, можно применить все свои навыки убеждения, просто "продавить" свою позицию и успокоиться. Например, можно безапелляционно заявить: "Да я просто в этом уверен!", и проигнорировать все остальные доводы. Но это не всегда работает, особенно, если вы ниже рангом, чем те, кому вы доказываете свою позицию.

Было бы неплохо иметь возможность перевести свои "интуитивные ощущения" в какую-то более осязаемую форму. В такую форму, которая бы позволила:

Осознать свои собственные ощущения
Проверить различные догадки
Наглядно и доходчиво объяснить остальным, почему то или иное решение будет более эффективным

Понятно, что при неадекватном восприятии никакие модели не убедят человека в неправильности решения. Модель помогает не столько убедить кого-то, сколько разобраться самому в своих доводах.

Системы поддержки принятия решений

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

Имитационное моделирование

Наиболее полно этим задачам соответствует метод имитационного моделирования. Этот метод позволяет строить модели, описывающие процессы так, как они проходили бы в действительности. Такую модель можно «проиграть» во времени как для одного испытания, так и заданного их множества. Стоит, однако, помнить, что модель всегда остаётся моделью. Она никогда не сможет учесть всех факторов, но с определённой степенью достоверности позволяет делать обоснованные заключения.

Инструменты для моделирования

Существует множество разных инструментов для моделирования. Среди них AnyLogic, GPSS и другие. Каждая из них обладает своими преимуществами и своими недостатками. У каждой из них есть свои приоритетные области применения. Не буду пытаться сравнивать эти системы, так как это выходит за рамки данного топика.

В этой статье в качестве примера я буду рассматривать систему iThink компании isee systems, inc. Эту систему я выбрал, во-первых, потому что именно про неё я услышал впервые, прочитав книгу Deadline Тома ДеМарко, а во-вторых потому, что она мне субъективно показалась наиболее простой для проведения моделирования специфических для управления проектами задач.

Пример

Постановка задачи

Для простоты понимания возьму за основу пример из той самой книги, о которой я говорил выше - Deadline. В ней главный герой, мистер Томпкинс, и доктор Джамид моделируют изменение производительности команды в зависимости от разных условий. У нас "ситуация с женщинами" очень похожая, поэтому пример вполне подходит. Справедливости ради надо отметить, что, на самом деле, оригинальным источником этого примера является книга «Introduction to Systems: Thinking and ithink». (Hanowr, N H High Performance Systems, Inc, 1994).
Для построения модели создам новый файл в iThink и на вкладке "Model" начну добавлять её элементы.
Но прежде нужно выделить факторы и численные величины для моделирования.

Факторы

Для того, чтобы сократить пространные рассуждения в романическом стиле, коротко выделю те факторы, которые могут влиять на модель:

Набор персонала в проект
Стоимость интеграции новых членов в команду
Отрицательный эффект масштаба
Эффект слияния от совместной работы

Числа

Далее нам необходимо выделить величины, которые могут быть каким-либо образом измерены. В данном случае без этого моделирование будет невозможно.
Итак, наши численные величины - это:

Количество сотрудников
Объём реализуемого функционала в условных единицах (функциональные единицы)

Построение модели в iThink

Для того, чтобы проще было воспринимать модель, начну её построения с конца.
Возьмём два контейнера. Один - полный, будет символизировать собой работу, которую необходимо сделать. Второй - пустой, будет символизировать собой работу, которую команда уже выполнила. Соединим их через вентиль, который будет определять, как быстро работа из первого контейнера будет перемещаться во второй. Таким образом, этот вентиль будет характеризовать производительность команды по выполнению необходимой работы. К сожалению, iThink не очень хорошо дружит с русскоязычными подписями, поэтому все подписи буду делать на английском.

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

облачко - ресурс-пул, откуда берутся новые сотрудники (для упрощения считаем бесконечным)
вентиль Income Staff - показывает, с какой скоростью люди поступают на обучение
контейнер New Staff - отражает сотрудников, находящихся на обучении
вентиль Integration Level - показывает то, с какой скоростью люди вливаются в команду после обучения
контейнер Effective Team - содержит сотрудников, представляющих из себя эффективно работающую команду

Далее нам необходимо связать между собой персонал (количество сотрудников) и изменение объёма реализованного/нереализованного функционала (в условных единицах). Для этого введём ещё один элемент в нашу модель - конвертер. Конвертер - это формула (правило), который преобразует одни числовые величины в другие. В данном случае конвертер будет отражать так называемый отрицательный эффект масштаба - diseconomies of scale, т.е. то, насколько менее эффективен будет каждый последующий добавленный член команды. Это поправку я заложил в виде умозрительного графика.

В iThink конвертеры могут задаваться как графически (набор значений, через которые проходит кривая), так и аналитически - в виде формулы.
Чтобы излишне не погружаться в детали модели и не создавать базу для споров, я не буду приводить здесь формулы. Уверен, что у каждого эти формулы будут свои.

На следующем этапе добавим ещё один конвертер - "стоимость интеграции" - Integration Cost. Этот конвертер будет показывать то, насколько снижается эффективность команды при внедрении новых сотрудников ("старожилы" вынуждены отвлекаться от своей основной работы для того, чтобы помогать новичкам).

Известен ещё один интересный фактор в командной работе - "эффект слияния" - Join Effect. Иногда со временем люди в команде становятся не просто суммой отдельных индивидуумов. Люди становятся Командой! Поддерживая друг друга, они начинают не только работать эффективней, чем если бы они работали поодиночке, но и легче принимать к себе новых членов команды - в дружный коллектив легче влиться (к сожалению, бывает и наоборот). Для упрощения модели укажем, что этот фактор определённым образом влияет на фактор стоимости интеграции.

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

Совершенствование модели

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

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

В общем, простора для творчества достаточно. :)

Принятие решения

Теперь, собственно, о принятии решения. Полученная модель помогает принять решение о том, до каких пор "вливание" новых членов в команду остаётся ещё достаточно эффективным.
Для того, чтобы понять, что будет происходить, запустим модель.

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

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

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

Заключение

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

UPD: По просьбам трудящихся здесь доступна сама модель. Можно поэкспериментировать.

Почему тестирование занимает так много времени?

2010-01-11T02:09:00.000-08:00

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

Избранные цитаты:
"Если вы работаете в тестировании достаточно давно, вам наверняка задавали этот вопрос — «Почему тестирование занимает так много времени?» Может быть, у вас есть заготовленный ответ на этот вопрос, а может и нет. Здесь я предлагаю модель, которая, я надеюсь, поможет вам справиться с менеджерами, которые задают подобные вопросы."

"Наличие большого количества багов вызывает либо уменьшение покрытия, либо замедление тестирования, либо и то и другое сразу."

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

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

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

Полностью статья доступна здесь: http://software-testing.ru/library/testing/general-testing/911-why-is-testing-taking-so-long

Учёт рисков при оценке трудоёмкости ПО и планировании проекта

2009-12-14T11:51:00.000-08:00

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

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

Типичные риски

Ниже приведу список типичных для проекта по разработке ПО рисков.

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

Что НЕ является риском

Является ли риском глобальное потепление? А изменение ситуации на рынке? А возможный распад компании заказчика или, не дай Бог, вашей компании?
Правильнее спросить так: "Какие из этих рисков нужно учитывать в вашем проекте?"

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

Просмотрев этот список, мой предыдущий руководитель и наставник сказал нам: "Не надо закладывать свой непрофессионализм в риски!" Как? Меня и моих коллег обвинили в непрофессионализме?! Я тогда немного обиделся на него. Мы были вынуждены исключить довольно много пунктов, которые нам действительно казались рисками. С тех пор прошло некоторое время, я немного остыл, почитал книги, переосмыслил свой предыдущий опыт. Теперь я могу сказать, что вынужден с ним согласиться по ряду пунктов. Итак, перечислю некоторые случаи, которые не стоит считать рисками.

Риски, вероятность которых стремится к 100%

недостаточная квалификация сотрудников - это не риск по той причине, что квалификация должна изначально закладываться в оценки (например, используя фокус-фактор)
регулярные отпуска сотрудников - их можно спрогнозировать более или менее заранее и внести в план проекта
прогнозируемые изменения требований - могут возникать в случае выбора определённой модели разработки (например, Fixed Team)

Риски, вероятность которых стремится к 0

Этот список может показаться немного надуманным. Он приведён только для иллюстрации возможных "невероятных" рисков. Важно понимать, что одни и те же риски могут становиться невероятными в зависимости от характера проекта и его продолжительности.

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

Работы, которые являются частью проекта или методологии

ревью кода - бывает, что эту активность относят к рискам
рефакторинг - говорят так: "может потребоваться рефакторинг". Слово "может" сбивает с толку и наталкивает на мысль, что это риск. По сути же, рефакторинг относится к тем работам, которые планируют заранее.

Учёт рисков при планировании

Тут нужно сделать небольшое лирическое отступление и объяснить, почему риски необходимо учитывать. Как говорил Том Де Марко, "чтобы управлять проектом, достаточно управлять его рисками". Но! Это касается момента, когда проект уже стартовал. Когда есть, чем управлять. А теперь представим, что оценка и планирование проекта ведётся ещё до его старта. И вообще неизвестно, будет ли проект запущен или нет. Нужно ли учитывать риски на этом этапе? И да, и нет...

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

Определение терминов

Введём понятие "чистой трудоёмкости"
Чистую трудоёмкость определим как трудоёмкость в "идеальных человеко-днях", необходимую для реализации той или иной задачи. Для объяснения, что же здесь имеется в виду, я воспользуюсь описанием, взятым из книги Scrum and XP from the Trenches от опытного Scrum Master'а Henrik Kniberg'а. Итак:

"Идеальный человеко-день – это максимально продуктивный день, когда никто и ничто не отвлекает от основного занятия. Такие дни – редкость." (с) Henrik Kniberg

Другими словами, будем считать, что задача обладает такой трудоёмкостью при условии, что ни один из рисков не реализуется.

Равномерное распределение рисков по задачам или методика "спрятанной шляпы"

В качестве "вводной" приведу анекдот, рассказанный нам одним из топ-менеджеров в ответ на представленные оценки недавнего проекта:

Сотрудник приезжает из командировки, подаёт expense report, а там, среди прочего, значится «Шляпа: $100»
Его в бухгалтерии спрашивают..
- Что за шляпа такая?
- Ну купил себе шляпу.. классная.. все дела.
- $%&*#! Иди меняй отчет!
Ну приносит новый, там опять «Шляпа: $100»
Ну опять "$%&*#!", иди меняй, чтобы не было никакой шляпы.
Приносит… Смотрят - нормально все… не подкопаешься, шляпы нет… но сумма финальная как была так и осталась.
Спрашивают:
- А шляпа где?
- Да там она… там… только вы ее хрен найдете!

Так вот, подобный метод можно применить и при учёте рисков.
Например, один или несколько рисков, выраженные в виде некой дополнительной трудоёмкости, можно просто равномерно распределить по остальным конкретным задачам, как указано на фрагменте диаграммы Ганта ниже:

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

Выделение самостоятельных задач

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

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

Теперь обратимся к другой диаграмме:

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

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

Выводы

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

Прошу простить, если топик оказался слишком длинным. Я и так ограничивал себя, где только мог. В частности, в посте совсем ничего нет о том, каким образом учёт рисков можно использовать в методике PERT. Если тема окажется достаточно востребованной, то на эту тему будет создан отдельный топик.
Спасибо тем, кто дочитал до конца!

Десять смертных грехов в оценке трудоёмкости разработки программного обеспечения

2009-11-27T04:27:00.000-08:00

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как "перевод". В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив - автор книги "Software Estimation. Demystifying The Black Art" - одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно - милости прошу в комментарии, можно будет меня поправить.

Десять Почти Смертных грехов в оценке трудоёмкости разработки ПО

Для "разогрева" Стив сначала перечисляет "почти смертные грехи", т.е. ещё не самые страшные, но всё равно очень серьёзные. Он их практически не комментирует.
Итак, по мнению Стива, Почти Смертными грехами в оценке трудоёмкости являются следующие вещи:

20. Оценивать сколько времени займёт сделать "ЭТО" до того, как кто-нибудь разберётся, что же "ЭТО" всё-таки такое
19. Предполагать, что наиболее достоверные оценки поступают от людей с самыми сильными голосовыми связками
18. Рассказывать кому-либо, что Вы пишете книгу по оценке трудоёмкости ПО, потому что они спросят "И когда вы планируете закончить свою книгу (прим., оцениваете срок окончания)?"
17. Делать оценки нового проекта, сравнивая его с предыдущим проектом…

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

… в котором было очень много внеурочной работы… и в итоге понимая, что Вы так же закладываете много внеурочной работы в новый проект
16. Предполагать, что отдел продаж делает оценки лучше, чем сами разработчики
15. Делать оценки, предполагая, что никто не пойдёт на тренинг...

… не пойдёт на митинг… никого не "сдёрнут" на другой проект… никто не потребуется для поддержки "ключевого заказчика"… не пойдёт в отпуск… не заболеет...
14. Давать оценки с высокой степенью точности (напр., "64,7 дня") в то время, когда они основаны на оценке с низкой точностью (+- "2 месяца")
13. Верить, что результаты оценки, выполненные в коммерческом ПО, не идут ни в какое сравнение с результатами, выполненными карандашом на салфетке
12. Рассуждать, что чем раньше мы начнём отставать от плана, тем больше времени нам потребуется, чтобы сократить отставание
11. Доказывать, что разработчики (прим., специально) занижают свои оценки так, чтобы они выглядели привлекательно

… последний проект, который удалось закончить раньше времени, был ещё при Рейгане!

Десять Смертных грехов в оценке трудоёмкости разработки ПО

1. Путать проектные цели и оценки

Типичная ситуация выглядит следующим образом. Руководство ставит задачу оценить трудоёмкость работы, добавляя при этом, что проект планируется показать на какой-нибудь ежегодной выставке где-нибудь за рубежом. Т.е., вроде как, и оцените, сколько надо... но надо тогда-то. Здесь оценка трудоёмкости перемешивается с целями проекта ( "показать на выставке в фиксированное время" ). Решение проблемы состоит в итеративном выравнивании целей и оценок. Например, для достижения цели можно уменьшить объём представляемого функционала, чтобы успеть всё сделать в срок.

2. Говорить "Да" тогда, когда вы, на самом деле, подразумеваете "Нет"

Часто складывается так, что за столом переговоров, за которым обсуждаются оценки/сроки, люди делятся на две группы. По одну сторону располагаются разработчики, которые часто интровертивны, молоды и редко обладают даром убеждения... а по другую сторону сидят экстравертивные и "умудрённые опытом" сейлз-менеджеры, которые не только обладают навыками убеждения, но и, иногда, специально обучены убеждать. В такой ситуации очевидно, что независимо от качества оценок, "побеждает" тот, кто умеет лучше "убеждать", а не тот, чьи оценки более адекватные.

3. Давать обещания на ранней стадии Конуса неопределённости

Перед вами так называемый "конус неопределённости" (или неуверенности... кому как нравится).

Это график, на горизонтальной оси которого указано время, а на вертикальной оси - значение ошибки, которая закладывается при оценке трудоёмкости. Как видно из графика, с течением времени, по мере того, как становится известно всё больше данных об оцениваемом проекте, о том, что же конкретно и в каких условиях придётся делать, "разброс" ошибки становится всё меньше.
Суть же проблемы состоит в том, что нельзя давать обещания в тот момент времени (крайняя левая часть конуса), когда величина ошибки ещё слишком велика. Стив оценивает предел "уверенности" где-то в районе 1,5x, т.е. тот момент времени, когда вероятная ошибка будет составлять 1,5 раза как в большую, так и в меньшую сторону. Давать обещания раньше этого момента - заведомо подвергать себя слишком большому риску.

4. Предполагать, что недооценка оказывает нейтральное влияние на результаты проекта

На эту мысль автор неоднократно делает акцент и в своей книге (см. Введение). Взгляните на график ниже.

Левая часть графика показывает зону недооценки (underestimation), правая часть графика зону переоценки (overestimation). По вертикали откладывается стоимость ошибки. Из графика видно, что стоимость переоценки растёт линейно (по закону Паркинсона). В то же время стоимость недооценки увеличивается лавинообразно по мере того, как возрастает ошибка недооценки необходимых усилий. В случае недооценки прогнозировать дополнительные усилия куда сложнее, чем в случае переоценки.

5. Фокусироваться на методах оценки в то время, когда вы реально нуждаетесь в ИСКУССТВЕ оценки трудоёмкости разработки ПО

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

6. Делать оценки в "Зоне невероятности"

Здесь нужно пояснить, что же подразумевается под зоной невероятности. Для произвольного проекта представим вот такой диалог (прим. сильно сокращён):
- Смогут ли 12 разработчиков закончить Проект за 10 месяцев?
- Да, может быть - отвечаем мы.
- А 15 разработчиков за 8 месяцев?
- Ну да, - отвечаем мы - скорее да, чем нет.
- А 30 за 4?
- Вряд ли - становится очевидно, что 30 человек, скорее всего, не смогут сработаться за такой короткий срок.
- 60 за 2 месяца?
- Ну это уже смешно!, - ответите вы...
- А 120 разработчиков за 1 месяц?
- Ну а это вообще не смешно. Издевательство просто...
Из этого диалога видно, что "сжатие" сроков при заданной трудоёмкости не может происходить бесконечно - есть предел. Так вот идея данного пункта состоит в том, чтобы не производить оценок за этим пределом. Такие оценки не могут быть состоятельными. Предел "на сжатие", по мнению Стива, находится где-то около 25% от номинальных оценок.

7. Переоценивать выгоду от новых методов и технологий

Использование новых технологий сопряжено с:

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

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

8. Использовать только один метод оценки трудоёмкости

В этом пункте автор предостерегает от двух вещей:

от использования только одной методики оценки
от усреднения значений, полученных разными методиками

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

9. Пренебрегать специализированным ПО для оценки трудоёмкости

Моделирование при помощи компьютерных программ может повысить адекватность оценок. Естественно, использование специальных средств не гарантирует вам надёжность и адекватность оценок. Но при умелом использовании может заметно повысить их точность. Кроме того, автор даёт ссылку на сайт своей компании, где доступны бесплатные инструменты для проведения компьютерной оценки трудоёмкости разработки ПО. Одно из главных достоинств специального ПО в том, что результаты выглядят более убедительно для "потребителей" оценок.

10. Давать поспешные оценки

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

Заключение

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

Microsoft Customer Care Framework или как Microsoft предлагает заботиться о клиентах

2009-11-10T03:13:00.000-08:00

Введение

На фоне того, как Google пытается стать для нас Всем, приятно видеть, что и другие компании не сдаются и продолжают развивать новые сервисы и технологии…

Побывав на прошлой неделе в Microsoft, с удовольствием послушал рассказ о системе Microsoft Customer Care Framework. Более того, удалось побеседовать с одним из ведущих архитекторов этой системы.

О Системе

Коротко о том, что это за система и с чем её едят.
Сама компания Microsoft описывает свою систему следующим образом.

Microsoft Customer Care 2009 (CCF) - это сквозная программная инфраструктура для поставки составных приложений. Она (система) включает в себя как компоненты для разработки приложений, так и компоненты времени выполнения. Приложения, построенные на базе CCF, предоставляют унифицированный доступ к информации заказчика, распределённой по множеству корпоративных приложений, агрегируя различные режимы взаимодействия с заказчиком. ©Вольный перевод из MSDN.

Чтобы проще было понять, о чём идёт речь, попробую объяснить "на пальцах".

Типичный сценарий

Представьте себя сотрудником службы поддержки огромного банка. Вы сидите в наушниках с микрофоном и ждёте, пока на телефонную службу поступит звонок от разъярённого клиента. Теоретически клиент может позвонить по какой угодно проблеме. У него может быть заблокирована пластиковая карта, он хочет узнать, сколько ещё ему осталось платить по кредиту, уточнить детали условий нового вклада и т.д. Как правило, в банках за услугу или группу услуг отвечают разные приложения, с разными UI, в которых могут быть разные учётные записи авторизованных пользователей.
Теперь представим себе картину… Звонит клиент по какому-то из вышеперечисленных вопросов (а, может, и по нескольким вопросам). Ему отвечает сотрудник службы поддержки. Просит подождать минутку, пока он найдёт и запустит нужное приложение. Потом ещё минутку, т.к. ему нужно залогиниться под своей учётной записью именно в данной системе. Потом ещё минутку, т.к. сотрудник ошибся выбранным приложением. И вот наступает долгожданный момент… Сотрудник службы поддержки неожиданно понял, что ответить на данный вопрос он не может и нужно перенаправить звонок в другой отдел… В общем, немудрено, что в подобной ситуации клиент может просто не сдержаться и бросить трубку об пол в порыве ярости. Ну кому хочется висеть по 10 минут на трубке и по 3 раза объяснять одну и ту же проблему совершенно разным людям? Кстати, вполне возможно, что кто-то из вас уже оказывался в подобной ситуации на стороне клиента. Не было чувства, что банку на вас просто наплевать и он не заботится о своих клиентах?

Заботимся о клиентах

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

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

Поддержка SSO
UI всех приложений, необходимых оператору, отображаются в одном окне на разных закладках
Так как интеграция происходит на уровне UI, разработка интеграционного приложения происходит очень быстро
Наиболее важные части платформы поставляются с открытыми исходными кодами
Контекст клиента доступен разным интегрируемым приложениям
Система объединяет в себе различные средства коммуникаций
Система легко масштабируется

А теперь подробнее по каждому пункту.

Single Sign On

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

Единый UI

За счёт объединения UI оператору не нужно переключаться между приложениями. Вся информация удобно размещается в одном окне, включая общую контекстную информацию: клиент, проблема и пр. Тут может быть небольшая "засада". Если приложение рассчитано на высокое разрешение, то при размещении на закладках Agent Desktop'а могут появиться полосы прокрутки. Это может доставлять неудобство оператору.

Быстрая интеграция

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

Открытый исходный код

Да-да, Microsoft готова идти навстречу своим партнёрам и предоставляет исходные коды некоторых частей платформы, что позволяет реализовывать самые изощрённые методы интеграции. Как я понял, речь идёт об исходных кодах Agent Desktop'а. Возможно, что-то ещё.

Клиентский контекст

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

Многоканальное общение

Система также способна консолидировать разные каналы, по которым приходят запросы от клиентов. Это электронная почта, служба мгновенных сообщений, IVR , SMS и пр.
Такой подход позволяет хранить в одном месте все информационные потоки и получать к ним быстрый и лёгкий доступ.

Масштабирование

CCF построен на базе стандартных Microsoft Composite Application Blocks с учётом современных требований по многопоточности. Как уровень базы данных, так и уровень сервера приложений легко кластеризуется, что позволяет Системе обеспечивать бесперебойную работу в режиме "24*7" и выдерживать высокие нагрузки при работе с большим числом пользователей.

Немного технических деталей

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

Приложение, созданное на базе MS CCF, будет построено с учётом современных многоуровневых подходов.

База данных

В качестве базы данных, как и следовало ожидать, предлагается использовать Microsoft SQL Server. Уже на этом этапе Microsoft рекомендует подумать о кластере.

В базе данных хранится информации об аудите действий пользователей Системы и конфигурация, которая обновляется администраторами Системы. Кроме того, в БД сохраняется контекст пользователя в том случае, если необходимо перенаправить входящий звонок другому оператору.

Уровень сервера приложений

На уровне сервера приложений выполняются методы доступа к данным (предполагаю, что некий DAL), а также бизнес-логика, которая может быть описана в терминах WWF с использованием, кстати говоря, визуальных средств разработки.

Пользовательский интерфейс

UI представляет из себя классическое Windows .Net приложение, которое способно отрисовывать в себя (в закладки - Tab Strip Control) главные окна других приложений как Windows UI, так и Web UI. Хитрость решения состоит в том, что Agent Desktop оборачивает вызов других приложений таким образом, что они отрисовывают себя не на Desktop (как это происходит по умолчанию), а в закладки самого Agent Desktop'а.

Обмен данными происходит прямо через элементы управления окон (в случае Windows приложений) или через HTTP-GET, HTTP-POST, SOAP (в случае Web-приложений). Благодаря такому подходу не требуется согласование интерфейсов между агрегирующим приложением и его агрегатами.

Ещё раз отмечу, что приложения могут ничего не знать о существовании родительского окна (Agent Desktop'а) и других приложений, с которыми происходит интеграция. Они не обязаны быть написаны по каким-то жёстким стандартам или с поддержкой каких-то строгих протоколов. Это могут быть самые обычные windows, web приложения или даже консольные терминалки, которые используются в компании уже много лет. Нет необходимости их как-то адаптировать или переписывать. Всё происходит прозрачно для них самих.

Заключение

Как видно из описания, Система, построенная на базе MS CCF, позволяет заметно сэкономить время, а также уменьшить количество ошибок в процессе обслуживания заявок клиентов. Что, в свою очередь, означает снижение стоимости обслуживания и повышение уровня удовлетворённости Клиентов. В целом, эта штука мне показалась довольно интересной. Прежде всего, интересной по своей, на мой взгляд, оригинальной идее - интеграции на уровне UI. На самом деле, здесь я описал только верхушку айсберга. Я совсем не затронул возможности CCF, связанные с интеграцией с BizTalk, с инфраструктурой SOA и т.д. Всего и не осветить в рамках данной статьи. Надеюсь, удастся "пощупать" её где-нибудь в более реальном применении и тогда уже поделиться с вами деталями применения. Спасибо, что дочитали до конца.

P.S.: Более плотно с описанной выше платформой можно ознакомиться здесь.
Технические статьи тут.