Перевод статьи Эли Шрагенхайма. Часть 3. Шесть вопросов о ценности новой технологии и как их применить к разработке новых продуктов

vintage-telephone-on-blue-background-header.jpg

Вопрос 1: В чем сила новой технологии?

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

Читать дальше

Перевод статьи Эли Шрагенхайма. Часть 2. Концепция восприятия ценности

new-technology-14758510078_26154ff376_header.jpg

Впервые эти шесть вопросов появились в книге «Цель-3. Необходимо, но недостаточно» (Голдратт, Шрагенхайм, Птак, 2000) и включали в себя анализ модулей ERP систем, заменяющих (в действительности  — лишь расширяющих) MRP систему (изначально MRP1[i] позднее превратившейся в MRP2).

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

Читать дальше

Перевод статьи Эли Шрагенхайма. Часть 1. Проблемные области принятия решения в управлении проектами

calendar-date-time-month-week-planning-paper-1-800-header.jpg

Применение общих подходов Теории ограничений, методологии составления графиков проектов и контроля за реализацией единичных проектов получила название Управление Проектами Методом Критической Цепи (CCPM). Позднее эта методология была также расширена на управление в условиях мульти-проектного окружения. Тем не менее, Теория ограничений до сих пор не внесла значительного вклада в другие критически важные области принятия решения в управлении проектами.

Читать дальше

Перевод статьи Эли Шрагенхайма «Проекты по развитию продуктов: рекомендации по оценке потенциала новых продуктов и планированию различных характеристик продукта в проекте»

examination-of-eyes-header.jpg

Существует три проблемных области принятия решения в проектном управлении, где ТОС [i] должна оказать значительное влияние:

  1. Как выбрать проект?
  2. Как выбрать конкретные характеристики продукта [ii] для данного проекта?
  3. Как управлять графиком проекта и его реализацией?

 

Читать дальше

Календарь на год

chess-pexels-photo-65169.jpeg

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

Читать дальше

Деловая игра "Самые важные документы проекта"

План управления проектом

Итак, мы, Алексей Васильев и Руслан Лазуков провели деловую игру по самым важным документам проекта в Санкт-Петербургском сообществе менеджеров ИТ проектов (SPB SPM Club). Точнее это был тренинг. Тренинг на отработку навыка написания Устава проекта и Плана управления проектом.

Читать дальше

IT Global Meetup #9 - Новогодний слет IT-сообществ Санкт-Петербурга

IT Global Meetup #9

Новогодний слет IT-сообществ Санкт-Петербурга!

Суббота, 3 декабря 2016 с 11.00 до 19.00, Санкт-Петербург, пр. Медиков д.3, КДЦ “Club House”.

bg_6.png

Читать дальше

Манифест философии BIPULSE

rails-003.jpg

Никакое ИТ решение не может реально помочь, когда нет подкрепления методологией обеспечения коммуникаций в компании или команде проекта и фокусирования целях. Поэтому, BIPULSE будет наиболее эффективен если следовать принципам Agile, Теории Ограничений Систем и Бережливого производства которые мы свели в 7 простых правил.

Читать дальше

Что делать если не успеваешь сделать работу в срок

Как успеть сделать в срок?

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

  • Внешние обстоятельства которые помешали,
  • Привычка откладывать все на последний момент,
  • Оптимистичные оценки относительно трудоемкости,
  • Сработал Закон Паркинсона: работа заняла все отведенное на неё время
  • Исходные данные пришли поздно.

И когда вы уже понимаете что явно не успеете, начинаются метания: "А что делать?"

Читать дальше

Откуда мифы про Agile

dragon-32887_640.png

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

Читать дальше

Качество команды или опять о производительности

Что такое качество команды? В каких попугаях его мерить?

snake.jpg Качество команды величина субъективная, однако его можно выразить через скорость поставки качественного продукта решающего задачу клиента. Если записать это в терминах ТРИЗ, через идеальный конечный результат, то получим, что качественная команда поставляет качественный Продукт за ноль времени, и потери связанные с переделкой сделанной работы отсутствуют.

Но если мы знаем, что такое качество, и оно нас не удовлетворяет, то как мы можем его улучшить? Как улучшить то, что нельзя пощупать?

Читать дальше

Правильные и неправильные задачи

revlolver.jpg В любой проектной деятельности самым базовым элементом планирования работ является "Задача". И это в корне отличает Проект от деятельности по сопровождению продукта, в которой основной элемент вокруг которого все вертится, это "Инцидент".

Формулировка Задачи должна отвечать на вопрос "Что мне надо сделать чтобы завершить проект?" , в отличии от инцидента: "Что произошло? И почему пользователь несчастен?"

Читать дальше

Надежный SCRUM

График расхода буфера критической цепи Что такого плохого в гибком (Agile) подходе к управлению проектом по разработке программного обеспечения? Особо ничего, если не считать того что завершение проекта в срок не стоит целью этой методологии.

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

Читать дальше

Оценка производительности команды

blog-performance-chart.png Иногда может сложиться впечатление что ваша команда работает медленнее чем обычно. Это может быть субъективное впечатление, а может быть и на самом деле так. Обычно рекомендуют в таких случаях, для исправления ситуации, менеджеру проекта поговорить с каждым участником команды..

Читать дальше