Информационные системы

Интересная статья про определение приоритетов задач при разработке ПО.
Описывает три метода: модель клиентской удовлетворенности Кано, серия инновационных игр от Люка Хохмана и модель относительных весов Карла Вейгерса.

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

Интересная Модель Кано - как работать с тем, что удовлетворенность не линейно зависит от объема реализованных требований.
Рекомендуется всем, кто стремится усладить заказчика. :-)

Цитата:

Графики Кано наглядно демонстрируют: «привлекательные» и «одномерные» характеристики – вот те две категории, которые способны вызвать восторг и обеспечить удовлетворение клиента. Именно на этих характеристиках сегодня сделан акцент у наиболее успешных продуктов.

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

Модель Кано показывает, почему лояльность клиентов нельзя получить и сохранить лишь за счет улучшения существующих характеристик, а также позволяют оценить эффективность вложений в их улучшение.

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

Я бы только понятие СЛОЖНОСТИ ХАРАКТЕРИСТИКИ, используемое на диаграммах и в определениях, заменил всё-таки на ПРОРАБОТАННОСТЬ ХАРАКТЕРИСТИКИ. Т.к. формально тут сложность преподносится именно в этом понимании (чем более проработан, тем более сложен). Но термин "сложность" - отталкивает, а "проработанность" - привлекает.

Понятные и близкие ;-) выводы-причины, почему внедрения ERP (и не только ERP) проходят с таким скрипом: I Survived an ERP Implementation – Top 10 Gems of Advice I Learned the Hard Way

Это должен знать и принимать во внимание каждый, кто начинает внедрение! :-)

Немного "теории" о том, что большой командой управлять сложнее ;-) : Communications Is the Key to Project Success by Jeff Hodgkinson

Цитаты:

• ...always weight the benefit of adding another member to your project team. If that team member is dedicated only a small percentage of their time to your team you and your other team members still need to spend the time and effort to communicate with that person the same as if they were full time.
• As the saying goes, “Trying to do too many things is the mark of ineffective people...”.
• The goal with fragmentation is to minimize the conflict between managing the work and doing the work itself.

Интересная тема про контроль значений - какие рамки для контроля выбирать.

Excel. Вычисление стандартного отклонения для данных с тенденцией
Пример построения контрольной карты Шухарта в Excel
Контрольные карты Шухарта

Текущие выводы для себя:

• контроль значений выполняется в рамках µ ± 3σ, где
  µ - среднее значение (за весь период/по всем рядам)
  σ - стандартное (среднеквадратичное) отклонение (функция в Excel'е - СТАНДОТКЛОН)
• "В соответствии с концепцией Шухарта именно такое определение границ позволяет отделить ситуации, когда экономически целесообразно начинать поиски особых причин вариации; пока такие границы не превышены, процесс остается статистически управляемым, и поиск причин отклонения отдельных значений является экономически нецелесообразным." (c)
• рамки µ ± 2σ - в случае выхода за пределы µ ± 2σ информировать ответственных, что ситуация близка к проблемной

Статья-перевод про выводы, которые сделал основатель проекта Sonar, из его провала.

http://siliconrus.com/2013/09/sonar-failure-lesons-learned/

Особо понравилось:

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

"Думайте про вашу корпоративную культуру как про кофаундера, который работает, пока вас нет на месте. Вы можете быть сколь угодно решительным, общительным и полезным основателем, но именно культура определяет, чем занимаются ваши сотрудники, когда вас нет на работе.
Только избегайте пустословия. Лучше показать пример на себе, работая изо всех сил и выкладываясь на 100%. Потом, если захотите, напишете это на листе бумаги и повесите у себя в офисе. Если вы были честны с собой и с командой, это станет культурой вашего стартапа."

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

Много сказано об отношении к автоматизации бизнеса (читай: внедрению Корпоративных Информационных Систем, ERP-систем, MRP-систем и т.д.) как к панацее. В какой-то момент Смолл Босс понимает, что стал Биг Боссом: бизнес разросся, бабки текут, "контора пишет", но что именно "пишет контора" - не всегда понятно. И в этот момент какая-то "светлая голова" говорит: "Дык, это... Программа нужна!.."