• Система менеджмента качества: как разобраться в стандартах и запустить процесс их внедрения в компании
    0
    Отличные схемы! Спасибо большое!
  • Мифы о CMMI, или кому и зачем она нужна
    0
    С одной стороны — руки не доходят, с другой — спокойнее стала относиться к непониманию, не задевает, а следовательно нет вдохновения :). К тому же пугает объем работы — Подобное описание означает Краткий курс Software Engineering, Project Management и управление организацией )))
    Может, как-нибудь соберусь…
  • Давайте, вначале, уволим всех менеджеров!
    0
    ISO сертификация может также и увеличить количество менеджеров ))) если неправильно внедрять. А если правильно — то все сертификации типа ISO предполагают наличие бизнес-процессов, которые дают представление об ожидаемом результате, точно указывают кто это должен делать и кому при каких условиях отдавать. Так сокращается время на ожидание указаний-фидбэков, вероятность того, что сделают не то, что нужно, то есть переработки.
    Правильно подобранные тулзы дают возможность получать инфу без привлечение специальных сборщиков, в том числе координаторов.
  • Давайте, вначале, уволим всех менеджеров!
    0
    Количество менеджеров легко сокращается при наличии работающих бизнес-процессов и ответственностей, встроенных в процесс. Бизнес-процесс указывает куда обратиться по какому вопросу и откуда какие данные взять. А для этого еще и инструментарий нужен, более продвинутый, чем excel. В общем, думать нужно.
    А до тех пор без менеджеров никуда, кто ж будет всю инфу собирать, передавать (!) и в excel запихивать :)
  • Мифы о CMMI, или кому и зачем она нужна
    0
    Спасибо за понимание :)
    Попробую ответить:
    1. Интересно было бы подробнее узнать, какие это уровни. Не уверен что коллективу из 50 человек может быть нужен 4-й уровень, а если даже и нужен, то непонятно как этот уровень в естесственных (не навязанных заказчиком, менеджментом, еще кем либо) условиях может поддерживаться
    Статистика не засекречена, смотрите тут http://www.sei.cmu.edu/cmmi/casestudies/profiles/pdfs/upload/2011SeptCMMI-2.pdf.
    В целом, Вы правы, чаще они идут на 2-3 уровень. Но выше им и не надо. Уровень 3 покрывает практически все необходимое. Уровень 4 требует очень большого прыжка и зрелости и людей и компании. Когда у компании появляется все необходимое для 4 уровня, она уже, скорее всего, выросла больше 100 человек :).

    2. Не совсем понятно зачем понадобилось усиление контрактной составляющей.
    Наш менеджмент решил, что нам надо быть ну очень Agile. Делали ставку на постоянное общение с заказчиками, не закрепляя практически ничего в контрактах. Потеряли деньги, пришлось ввязаться чуть ли не в суд, то есть опять растраты… ну и прочее. В общем, обожглись на «слабой контрактной составляющей».
    По поводу навязывания процессных моделей. Речь не о навязывании процессных моделей, а про адаптацию (tailoring) процесса. Если мы работаем по bodyshop модели — мы ничего не навязываем, как я и писала. Если мы берем на себя управление проектом, а соответственно и процессом, мы адаптируем процесс под конкретные условия. (Ну или стараемся это делать).
    3. Интересно было бы узнать о практике применения CMMI для аутсорсинга. Ведь есть отдельный раздел — CMMI for Acquisition, ориентированный на это.
    Это работает тогда, когда заказчик хочет наладить процесс получения продукта или услуги. Я не слышала никогда о таких заказчиках, которые применяют CMMI for Acquisition для этого. В общем, аутсорсинговая организация не может быть инициатором, вернее, это уж точно будет навязыванием клиенту процессных моделей :). Тут скорее интересно побольше узнать по CMMI for Services. Но эта модель еще слишком молода, и лично у меня еще не дошли до нее руки.
  • Мифы о CMMI, или кому и зачем она нужна
    0
    Согласна с Вами
    Было бы здОрово, если бы кто-нибудь разобрал CMMI практики именно с точки зрения потребностей. Описал — к чему приводит невыполнение той или иной практики.

    очень хочу это сделать, я уже выше писала про идею «CMMI для чайников».
  • Мифы о CMMI, или кому и зачем она нужна
    0
    Я правильно понял вашу мысль
    Да :)

    пример про требования хотел пометить тэгом sarcasm, но решил, что и так будет понятно
    понятно, я на всякий случай расписала
  • Мифы о CMMI, или кому и зачем она нужна
    0
    план работ должен быть консолидированным. ИМХО, это означает что я могу открыть один документ (файл, проект в проджекте, etc) и увидеть общий план проекта.… С тем же успехом можно сказать, что CMMI требует, чтобы у проекта были требования. Точно помню кто-то в почту мне присылал, а еще нашему директору кто-то смской пару замечаний отправил.

    В нашем документе есть разделы, необходимые для Project Management Plan, соответствующие всем базовым требованиям разных стандартов (они все примерно одинаковы для PMP). Эти разделы должны
    а) либо заполняться в самом документе, но во время, то есть до того, как этот раздел нужен для работы;
    б) либо ссылаться на описание всей необходимой для этого раздела информации, которая хранится в другом файле или инструменте. При этом все эти файлы и инструменты должны быть сохранены в специально отведенном для PMP хранилище (например, как у нас, SharePoint библиотека на сайте проекта).
    Эта информация, из каждого раздела PMP, независимо в каком формате она сохранена, обязательно должна быть:
    а. доступна из PMP (я его назвала «регистр» информации и ссылок)
    б. обязательно ревьюится всеми вовлеченными в работу по этому разделу людьми, а так же службой обеспечения качества (моя епархия)
    в. формально утверждается и «бэйзлайнится». Заказчику не всегда нужно (и хочется) видеть весь документ целиком. С заказчиком формально утверждается то, что ему нужно и что нам нужно от заказчика. Все целиком формально утверждается службой обеспечения качества или менеджером данного account-a.
    г. есть процесс управления изменениями, поэтому новые поступления либо вливаются в уже существующую информацию. Например, файл с описанием объема работ пересохраняется с новой версией.

    Таким образом, PMP — консолидированный, формально утвержденный, используется для контроля и управления. Информация не разбросана по смс-кам и почтам, а хранится в одном месте и содержит актуальную информацию.
    Что очень важно, эта информация всегда публикуется своевременно. И психологически легче для того, кто публикует и тех, кто читает. Это то же, что переслать письмо (часто это пересланное письмо и является новой версией документа).

    В вашем реестре отображается плановая дата завершения проекта?
    Дата завершения проекта в нашем случае отражается в MS project-e. На MS Project, как на расписание, задачи, зависимости ссылаемся из PMP (регистра информации и ссылок). В том же PMP должна быть ссылка на контрактные условия (к сожалению, работа с контрактом у нас пока слабое место, поэтому пишу «должна быть»), в которых тоже прописана дата окончания проекта. Собственно оттуда она попадает в расписание, или наоборот (в зависимости от того, когда подписан контракт).

    С тем же успехом можно сказать, что CMMI требует, чтобы у проекта были требования… Значит у нас уже полный CMMI и проводить сбор-анализ-документирование-согласование требований уже не надо. :)

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

    Попробуйте почитать CMMI. Если говорить CMMI-ными терминами, то, что нужны требования и какими они должны быть, описано в Specific Practices соответствующих Process Areas (в данном случае Requirements development and Requirements management), а то, как гарантировать, чтобы они были актуальны, доступны, известны, управляемы — в Generic Practices.
  • Мифы о CMMI, или кому и зачем она нужна
    0
    — Фишка в том что полезной она может быть только в случае если сама организация достаточно созрела для оптимизации и ее кадры понимают что делают. Но такой организации как правило уже не нужен костыль в виде формальных правил СММ.

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

    Другой путь — все таки взять на вооружение такие модели, как CMMI. Но взять на вооружение должно руководство, чем выше, тем лучше. Индивидуальный забег проджект менеджера или тим лида может привести к конфликту, разочарованию, или, в лучшем случае, к успеху этого конкретного проекта и этого конкретного менеджера.

    Все мы ходили в школу, читали учебники в институтах. Сейчас мы их уже, может быть кто-то за редким исключением, не перечитываем. Потому что созрели и поняли, и запомнили. То же и с моделями зрелости, стандартами и т.д.
  • Мифы о CMMI, или кому и зачем она нужна
    0
    Не совсем согласна. Снова получим плохую тушенку в случае если
    а. менеджер будет пренебрегать этапами процесса,
    б. менеджер не будет реагировать на метрики и другие знаки того, что процесс вышел из под контроля, и
    в. требования к выходному продукту каждого этапа производства будут снижены
    или не будут проверяться (что есть пренебрежение процессом)
  • Мифы о CMMI, или кому и зачем она нужна
    0
    Попробуйте почитать требования. И сложить их в систему.

    Тут всех пугает кажущаяся сложность текста. Поэтому читать стоит людям подкованным в нескольких инженерных и управленческих областях.

    И потому же я теперь уже однозначно буду писать «CMMI для чайников» :).
  • Мифы о CMMI, или кому и зачем она нужна
    0
    Развенчание второго мифа заключается в том, что как маркетинговый ход это может и не сработать, не стоит на это особенно надеяться.

    Не сработать может по двум причинам — либо клиент на это «не клюет», либо «клюнул», потом приехал посмотрел своими глазами и разочарованный уехал.
  • Мифы о CMMI, или кому и зачем она нужна
    +1
    Можно наладить суперский процесс производства продукции разных сортов. Даже той тушенки о которой Вы говорите. Процесс гарантирует однородность и повторяемость. Если вся тушенка одинаково «дерьмовая», то производство преуспело в процессе :).

    Другое дело, стоит ли за производством задача улучшения и роста. Вероятно у производителя этой тушенки — нет. Возможно, производителя устраивает и спрос и себестоимость.
  • Мифы о CMMI, или кому и зачем она нужна
    0
    Там в начале статьи есть ссылки на базовую информацию, о чем уже писали на Хабре
  • Мифы о CMMI, или кому и зачем она нужна
    0
    У каждой статьи свой читатель. Значит Вы знаете много. Мой опыт показывает, что далеко не все такие образованные в этом плане.
    Я пишу статьи чтобы «забэйзлайнить» свои мысли. Возможно, я до Вас еще не доросла.

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

    Наоборот, я говорю об ошибках, которые совершили мы, поверив в мифы про CMMI.
  • Мифы о CMMI, или кому и зачем она нужна
    0
    Да я, собственно, не агитирую. Более того, мыслью подтолкнувшей меня на написание статьи было «не трогайте CMMI, если Вам это действительно не надо». Кому и зачем надо — я написала. Так же, сделала акцент на том, что применение (реализация конкретных практик) зависит от профессионального кругозора тех кто применяет и от знания всей модели, а не отдельных ее частей.

    Как я уже ответила уважаемому 1nd1go, который просил больше примеров, Вы наталкиваете меня на мысль о цикле статей «CMMI для чайников» :). Я привела несколько жизненных примеров, когда стоит и когда не стоит применять CMMI, пару примеров реализации практик. Задачей этой статьи не было объяснение большинства практик простыми словами. Те пример, которые я привела, показывают, что это возможно.

    Востребованность я поняла. Постараюсь оправдать Ваши надежды.
  • Мифы о CMMI, или кому и зачем она нужна
    0
    — а люди просто не понимают и отказываются когда видять, что надо описывать кучу макулатуры

    Абсолютно с Вами согласна. Как я уже писала, я не фанатка CMMI, очень долго сама пыталась разобраться что к чему :)

    — можете на пальцах объяснить, что положено, или какие именно практики заложены у вас в проектах

    Могу, возможно не все, но вот пару примеров в статье привела. В принципе, Вы наталкиваете меня на мысль о цикле статей «CMMI для чайников» :).
  • Мифы о CMMI, или кому и зачем она нужна
    0
    — компания сама не может быть стандартизована по CMMI, стандартизуется отдел или проект.

    Отдел или подразделение — Да. Но не проект. Хотя, если этот проект тянет на подразделение — то можно и так сказать:). В обиходе говорят «компания», имея ввиду, что в рамках этой компании есть подразделение, которое оценено на такой-то уровень. Так вот и у нас: есть bodyshop, который, разумеется, не входил в группу оцениваемых проектов.
    Однако, так как CMMI касается не только проектного управления, но и организационного, то даже при сосуществовании полного цикла оказания услуги и bodyshop есть общие организационные процессы, такие как, например, развитие персонала (в CMMI — Organizational Training).
  • Мифы о CMMI, или кому и зачем она нужна
    0
    — но гарантий это не дает.

    Не дает. CMMI говорит о потенциальных возможностях. Но не гарантирует, что каждый проект будет идеальным.
  • Мифы о CMMI, или кому и зачем она нужна
    0
    — Сомневаюсь (работаю в CMMI5 компании).
    Ваше право. Но нут возможны вопросы:
    а) играет ли этот статус какую-то роль для ваших клиентов? Если нет, то он и не будет пытаться вас «раскусить». (это по поводу маркетинга)
    б) работали ли Вы в «неCMMI5» компании? И как долго работали там и там? если да, работали и достаточно долго, то тогда действительно интересно услышать Ваше мнение по поводу сравнения этих компаний.
    в) Вы работаете в том подразделении, которое проходило оценивание? Или, скажем, в другом офисе этой компании (или в другом направлении)? Тоже интересно, есть ли отличия.

    Ну и, в конце концов, про Level 5. Судя по тому, что я слышала, этому мало кто доверяет. Как сказал один из наших потенциальных клиентов, «я буду работать с Level 3, так как тут меньше шансов фальсификации».
  • Мифы о CMMI, или кому и зачем она нужна
    0
    — Почему был выбран именно CMMI?
    Наше руководство решило, что нам это нужно. Какие у них тогда были соображения — я не буду предполагать.
    Насколько я помню, тогда же рассматривался вариант OPM3. Но от него отказались, вероятно потому, что CMMI, в принципе, включает и управление проектами. К тому же, видимо, на рынке клиентов спроса на OPM3 не было :). Точно не помню сейчас OPM3 (помню, что много общего), но CMMI включет помимо Organizational Project Management еще и Organizational Process Management, Engineering и Support области.

    — Не шашечки ли это — «уровень зрелости в целом», вместо «уровня зрелости вида деятельности».
    CMMI имеет варианты для Development, Services, Systems (и даже People). CMMI for Development, о котором и идет речь, рассматривает необходимые условия для работы IT подразделения, то есть «уровень зрелости IT подразделения/компании». Но я бы все-таки определяла немного по-другому: уровень зрелости управления IT подразделением/компанией.
  • Risk Management: предотвращение проблем vs. ведение регистра рисков
    0
    Не совсем поняла пожелание.
  • Risk Management: предотвращение проблем vs. ведение регистра рисков
    0
    Управление рисками — не самоцель, это инструмент для про-активных действий, для предотвращения возможных проблем, вместо тушния пожаров. Это инструмент коммуникации с руководством компании и клиентом.
    В статье я привожу примеры того, с чем я сталкивалась. И они не радужные. Они как раз свидетельствуют о наличии ненужной борократической процедуры — наличия регистра рисков с банальными проблемами.
    Сейчас передо нами (в нашей компании) стоит задача — устранить ненужную бюрокаратию и минимизировать «пожары» за счет «проактивного» менеджмента.
    За аудитом последовало исследование, тренинг и workshop-ы, изменились (стали жесче и конкретнее) требования к процессу управления проектами и определены точки контроля корректирующих действий.
    Эта статья как раз и является обобщением наших ресёрчей и брейнстормингов. Сейчас мы пытаемся внедрить те рекомендации, которые я описываю. Последующий контроль корректирующих действий покажет есть ли эффект.
    Обязательно поделюсь результатами.
  • Risk Management: предотвращение проблем vs. ведение регистра рисков
    +6
    О да, знакомо. Только Вася ему не сделает качество, которое он хочет. И в итоге он будет недоволен. Хотя, если Вася умный мужик, то он сделает то, что может и убедит, что именно это и нужно было :). А потом будет выманивать по баксу за каждый дополнительный чих.

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

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

    А в целом, чтобы «делать всё качественно, по стандартам, с анализом требований, составлением юзкейсов и ТЗ» нужно выходить на другой уровень фрилансерства. А для этого нужно постигать хитрости продаж и бизнесс анализа.
  • Объектно-ориентированный подход к управлению проектами
    0
    «календарный план уходит в прошлое»?
    по нашему опыту, большинство клиентов интересуют сроки в первую очередь, ну и конечно, чтобы поменьше людей привлекалось — вседь это влияет на стоимость заказа. В таких случаях без хорошей разбивки (breakdown) и календарного плана с учетом зависимостей никуда. Как еще объяснишь заказчику, почему так долго или так дорого?
    «Проект, в котором от начала до конца жил календарный план» — в коммерческих проектах он никогда не был и не будет одим и тем же. Он должен жить вместе с проектом. И возможно это только если делать достаточно детальный WBS (почему бы не основывать его на архитектуре), и связывать работы зависимостями.
    Кстати, у заказчика не всегда есть понимание того, что для него первостепенно важно, а что — нет, но намного чаще есть какие-то временные ограничения.
    Обсуждение календарного плана (и его поправок на изменения внешней среды) с заказчиком, покажут достаточно быстро, какие функции системы критичны для него а какие — могут подождать.