Тратить время предпринимателям.

Твитнуть

В избранное

В избранном

Джейсон Фрайд

Многие бизнес-проблемы возникают сами по себе. Многие раны люди причиняют сами себе. Конкурентов можно победить, но чаще всего конкурент проигрывает самому себе.

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

​Один из основополагающих принципов нашего бизнеса - избегание проблем. Это фундаментальная причина, по которой мы могли заниматься тем, чем мы занимаемся, на протяжении 18 лет. Мы не увеличивали штат, и наш бизнес приносит прибыль.

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

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

Рост

Мы преднамеренно избегали роста. Basecamp обслуживает более 100 тысяч платящих клиентов и несколько миллионов отдельных пользователей: но в штате компании чуть больше 50 человек.

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

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

Большие команды

Мы специально ограничиваем размер команд. Почти над каждым проектом в Basecamp работает команда из трех человек - дизайнера и двух разработчиков. Над некоторыми проектами работает команда из двух человек (дизайнера и разработчика), над некоторыми - один человек (дизайнер или разработчик).

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

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

Долгосрочное планирование

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

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

Сравните это с проектами, которые занимают полгода-год. О таких проектах говорят: «он слишком большой, чтобы провалиться» или «он будет готов, когда настанет время».

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

Планы и обещания

Как и в пункте выше - мы редко смотрим дальше шести недель. Конечно, у нас есть представление общей стратегии - где мы хотим оказаться в будущем, - но оно не зафиксировано в письменном виде. Ее стоит воспринимать в качестве «неофициальной устной традиции».

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

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

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

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

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

Дедлайны

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

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

Непонимание

У сотрудников нет проблем с коммуникацией - у них проблемы с взаимопониманием. С каждым дополнительным участником диалога количество «непонимания» растет по экспоненте. Как говорил знаменитый финский журналист Осмо Вийо: «Если коммуникация может нарушиться, она обязательно нарушится».

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

Партнерства

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

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

Помехи

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

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

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

Для всего того, что я написал выше, есть одна странная метафора. Это как посуда: если мыть ее сразу после еды, то в будущем не придется тратить на это время. Своевременность позволяет избежать сложной и ненужной работы.

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

Вы сами увеличивается уровень сложности работы. Почему возникают завалы? Потому что никто не находит в себе смелости сделать работу - «Ничего не случится, если я положу еще одну тарелку. Помою потом».

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

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

Проблема 2.
Раннее выявление и решение насущных и плохо решаемых проблем.
Чтобы обучаемый мог действовать в изменяющемся мире, он должен не только понять (проблема 1.)и запомнить факты (или типовые решения), но и уметь заранее выявлять проблемы и эффективно их решать. Что бы не оказаться у разбитого корыта м всегда суметь найти выгодную нишу для себя.
Поэтому я — за новую обучающую систему, в рамках которой будут учить не знаниям, а методам. Можно сказать: сегодня уже не «знания - сила», а «креативность (метод) сила».

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

Всему этому учит теория решения изобретательских задач — ТРИЗ . Она основана на алгоритмах решения задач. Каждый шаг алгоритма — это тяжёлая творческая работа. Но наши читатели сюда пришли именно за тяжёлой работой, за интересной тяжёлой работой, которая может в корне изменит их жизнь.

«Как определить, в какую сторону течёт вода в трубе?» Не очень сложная задача, но инженерам, впервые решившим её, выдали авторское свидетельство на изобретение.

«Надо прогреть трубу паяльной лампой. «Куда бежит жидкость, там труба будет теплее». Совершенно верно, это простой и надёжный способ.
Вы думаете, это интуиция, озарение? Нет, это результат продвижения по алгоритму.

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

Или вот ещё пример.

Старый охотник всегда брал в тайгу собаку. Когда она отыскивала зверя, торопился на её лай. Но случилась беда: охотник оглох. Как же теперь искать зверя? Чтобы собака вышла на след, ее надо отпустит -пусть бегает, ищет. А чтобы видеть (раз уж нельзя слышать), как ведёт себя собака, её надо держать при себе, рядом. Противоречие! Убежит собака на полсотни метров — её не увидишь. Держать охотничью coбаку на привязи, даже длинной, тоже не годится.
Собака отыскивала зверя, загоняла его на дерево, и охотник, ориентируясь на лай собаки, спешил к этому дереву. Но случилась беда - охотник потерял слух. Как же теперь охотиться?
Есть и немало ошибочных решений.
Например, такое: пусть охотник держит собаку на длинной привязи, Конечно, привязь поможет охотнику отыскать своего помощника. Но подумайте, насколько эта привязь затруднит движения собаки! Ведь лайка бежит не по ровной местности, кружит среди деревьев. Привязь будет цепляться за стволы, мешать собаке или даже вообще её останавливать. Видите, что получается: выиграли в одном и проиграли в другом. А хорошее решение должно быть таким, чтобы выигрыш не сопровождался проигрышем.
Во многих письмах встречается предложение: надо надеть на собаку передатчик, а охотнику дать в руки приёмник с направленной антенной (пеленгатор). Что ж, выигрыш очевиден, но есть и проигрыш. На собаку придётся навьючить передатчик и электробатареи, а старика охотника учить радиотехнике и спортивной радиоигре «охота на лис»…
«Нужны две собаки, — пишет девочка (3-й класс, г. Ярославль), - Одна собака будет бегать по лесу и искать добычу, а вторая пусть идёт у охотника на поводке и показывает дорогу к первой собаке». Вот тут всё верно! Решение предельно простое и надёжное.

Мы говорили об обучении. Трубы, треугольники, собаки…А как быть с нами? С любым читателем?

Тут два вопроса.

1. Существуют ли эффективные методы разработки и внедрения психологических и лайф-хаккерских инноваций, основанных на правильно организованном мышлении человека?
2. Есть ли методы эффективного обучения инноваторов в психологической и лайф-хаккерской среде? Не единичного, а массового обучения кадров для инновационной, инвестиционной и венчурной сферы - специалистов, которые могут кардинально поднять эффективность инноваций. Да и просто тех, кто может помочь любому думающему человеку сформировать картину мира, позволяющую эффективно действовать?

Я считаю, что ответ на оба вопроса — НЕТ.

Система лайф-хаккинга и психология сама по себе в современных условиях даёт сбои. Что на эту тему говорит ТРИЗ?

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

ТРИЗ существует давно, но она находится на первых этапах развития, так как система очень сложная. Некоторые части алгоритма ТРИЗ очень тяжелы для исполнения. Я считаю, что одним лучших способов облегчения прохождения шагов в алгоритме ТРИЗ будет использование системы логико — графического структурирования Егидеса.
А спасением для психологии является использование логических методик обработки информации, её поиска и визуализации. Егидес и ТРИЗ.

ТО есть
ТРИЗ+Егидес+Практическая Психология = быстрое реагирование

Конечно же, всё это не нужно тем, кому И ТАК ХОРОШО. Но действительно ли ТЕБЕ хорошо? Не чувствуется ли что то не то? Не спится ли плохо по ночам?

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

Твитнуть

Плюсануть

Отправить

Некоторое время назад обратил свое внимание на артефакт Концепция продукта (product vision) методологии разработки программного обеcпечения RUP (Rational Unified Process) и обнаружил, что отправной точкой разработки программного продукта является выявление проблемы, на решение которой нацелен продукт.

Аналогичный подход существует и в отечественной практике – так в ГОСТ 34.601-90 говорится, что на стадии Формирование требований к АС (автоматизированной системе) производится «выявление проблем, решение которых возможно средствами автоматизации ».

Общая характеристика процесса принятия решений

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

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

С чего начинается родина решение?

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

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

Лицо, которое не только осознает проблему или желает что-то изменить, а еще и готово принять решение о способе ее решения и произвести конкретные действия, направленные на изменение действительного состояния в сторону желательного – называют заинтересованным лицом или лицом, принимающим решение (ЛПР).

Цель

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

Задача

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

Операция и решение

Когда перечень задач определился, ЛПР приступает к формированию целенаправленной деятельности организации по достижению цели. Целенаправленная деятельность комплекса мероприятий, осуществляемых ЛПР в интересах достижения намеченной цели носит название - операция .

Замысел операции постепенно дорабатывается ЛПР до решения на ее проведение, в ходе формализации которого оно трансформируется в систему частных целей и задач руководителей подразделений, программы развития, планы, задачи и критерии их выполнения. После этого начинается процесс практической реализации принятого и доведенного до исполнителей решения .

Рисунок 1. Типовой процесс управления организацией

Оценка эффективности управленческого решения

До самого конца операции ЛПР и все участвовавшие в разрешении проблемы лица остаются в неведении относительно успеха или неуспеха операции. Только когда деятельность участников завершится, ЛПР станет ясно, та ли предпосылка (первопричина) проблемы была выбрана для решения, правильно ли была сформулирована цель операции, верно ли эта цель была разделена на задачи, в то ли время и тем ли исполнителям было поручено эти задачи решить и т. д.

Когда решение исполнено, а операция по устранению проблемы завершена, ЛПР оценивает достигнутый результат. При оценке полезности и эффективности полученного решения во внимание принимается не только сам факт окончания операции, но и степень устранения изначальной проблемы.

В результате оценки можно прийти к следующим выводам:

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

Природа требований к программному продукту

Какая задача – такое и решение

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

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

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

Этот банальный пример показывает, что для решения разных задач должны использоваться разного рода решения. Казалась бы, очевидно! Не будем спешить с выводами…

Что такое требование?

В соответствии с определением, под термином автоматизированная система подразумевается совокупность персонала организации и комплекс средств автоматизации, реализующего информационную технологию выполнения действий, направленную на достижение определенной цели (см. ГОСТ 34.003-90). То есть используемое программное обеспечение должно обладать набором свойств, позволяющим персоналу выполнять действия или решать задачи, направленные на достижение поставленной цели. Указанные свойства программного продукта называются требованиями .

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

Уровни требований

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

Рисунок 2. Процесс создания автоматизированной системы

Потребность

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

Функция

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

Программное требование

После определения набора функций их детализируют в конкретные и законченные описания поведения программы, которую требуется разработать. Такие описаниями составляют программные требования или требования к программному обеспечению (software requiremens).

Оценка эффективности программного решения

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

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

Одна грустная история

Не так давно в больнице уездного города N я внедрял одну медицинскую систему, которая, на первый взгляд, соответствовала всем предъявляемым к ней функциональным требованиям. Однако в процессе опытной эксплуатации выяснилось, что пользоваться ей было совершенной невозможно – она кардинально ломала привычную логику работы врача. Вместо того чтобы помогать, она мешала. Сначала систему использовали только активисты, позже использование системы сошло на нет.

Почему так получается?

Кто виноват и что делать?

Очень часто в процессе сбора и анализа происходит искажение требований или же источник этих требований (проблема заинтересованного лица) не выявляется вовсе.

Рисунок 3. Искажение требований

На рисунке 3 показан пример процесса, в ходе которого возникают искажения. Когда ЛПР осознал проблему и сформулировал цель деятельности по ее устранению он доводит перечень задач (T 0) до исполнителей - персонала организации. Допустим, что именно эти исполнители будут использовать разработанный позднее программный продукт, т.е. они будут являться его пользователями. Каждый из них по-своему понимает поставленную ему задачу и при формулировании требований к программному продукту исходит из своих предположений (T 1).

Аналитик, на основании данных интервью потенциальных пользователей, сформулировал собственное представление о решаемых задачах (T 2), которое донес до менеджера проекта и совместно с ним выработал решение, воплощенное в задачах для разработчика (T 3).

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

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

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

Рисунок 4. Соотнесение требований с проблемой

Более того, понимание решаемой проблемы позволит качественно управлять масштабом проекта – например, в первую очередь реализовать ту функциональность, которая решает 80% проблемы.

Как этого добиться?

Определение проблемы

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

Многие источники предлагают использовать нижеприведенную форму для формулировки определения проблемы (problem statement), которую требуется решить. Приведенная форма учитывает и цели, которые ожидается достигнуть будущим решением.

Пример

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

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

Заключение

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

В настоящее время только 39% всех программных проектов можно считать успешными в полном смысле этого слова. Полностью проваливаются 18% проектов, а в ходе реализации оставшихся 43% возникают проблемы, связанные с превышением бюджета или реализацией не той функциональности.

В исследовании компании Standish Group International, результаты которого отражены в документе The CHAOS Chronicles 2013 , ключевыми факторами успешности программного проекта названы:

• вовлечение в проект заинтересованных лиц (Executive management support) - 20%;
• привлечение конечного пользователя (User involvement) - 15%;
• управление масштабом проекта (Optimazation) - 15%.

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

Все вышесказанное подтверждает аксиому, что программные продукты создаются для пользователей. Ориентация на проблемы заинтересованных лиц и потребности реального (конечного) пользователя является залогом успешности проекта по разработке программного обеспечения. Уже на начальном этапе проекта пользователь должен быть привлечен к работе, как результат этого - определение проблемы (problem statement) и концепция продукта (product vision) должны показывать, что команда проекта ясно осознает решаемую проблему, понимает потребности пользователей и готова их удовлетворить.

Первый шаг на пути решения проблемы ее определение или диагноз, полный и правильный. Как принято говорить, правильно сформулировать проблему - значит наполовину решить ее.
Существуют различные взгляды на сущность проблемы:
- Согласно одному, проблемой считается ситуация, когда поставленные цели не достигнуты или существует отклонение от заданного уровня, например, мастер может установить, что производительность труда или качество изделий на его участке ниже нормы.
- В соответствии с другим, как проблему следует рассматривать также и потенциальную возможность повышения эффективности.
Объединяя оба эти подхода, будем понимать под проблемой - расхождение между желаемым и реальным состоянием управляемого объекта.
Полностью определить проблему зачастую трудно, поскольку все части организации взаимосвязаны. В результате, диагноз проблемы сам по себе часто становится процедурой в несколько шагов с принятием промежуточных решений.
Первая фаза в диагностировании сложной проблемы - осознание и установление симптомов затруднений или имеющихся возможностей. Понятие «симптом» употребляется здесь во вполне медицинском смысле. Некоторые общие симптомы болезни организации - низкие прибыль, сбыт, производительность и качество, чрезмерные издержки, многочисленные конфликты в организации и большая текучесть кадров. Обычно несколько симптомов дополняют друг друга.
Выявление симптомов помогает определить проблему в общем виде. Это способствует также сокращению числа факторов, которые следует учитывать применительно к управлению. Однако так же, как головная боль может служить симптомом переутомления или опухоли мозга, общий симптом типа низкой рентабельности обусловлен многими факторами.
Для выявления причин возникновения проблемы необходимо собрать и проанализировать требующуюся внутреннюю и внешнюю (относительно организации) информацию. Такую информацию можно собирать на основе формальных методов, используя, например, вне организации анализ рынка, а внутри нее - компьютерный анализ финансовых отчетов, интервьюирование, приглашение консультантов по управлению или опросы работников. Информацию можно собирать и неформально, ведя беседы о сложившейся ситуации и делая личные наблюдения.
Увеличение количества информации не обязательно повышает качество решения. Руководители страдают от избытка не относящейся к делу информации. Поэтому в ходе наблюдений важно видеть различия между релевантной и неуместной информацией и уметь отделять одну от другой.
Релевантная информация (relevant - относящийся к делу) - это данные, касающиеся только конкретной проблемы, человека, цели и периода времени. Поскольку релевантная информация - основа решения, естественно добиваться, по возможности, ее максимальной точности и соответствия проблеме. Организации может быть не просто получить исчерпывающую точную информацию по проблеме.
Признание проблемы является необходимым условием для ее решения , так как если проблема не существует для того, кто принимает решение, то принятие решения не состоится.
При этом возможны ошибки, связанные со следующими обстоятельствами:
- проблема вам дана кем-то сверху и у вас нет выбора кроме как “признать” ее;
- желательно быстрое решение возникшей проблемы и не остается достаточно времени на ее признание;
- допустимо низкого качества решение и выше названная проблема может повторится;
- проблема хорошо знакома и к ней вероятней всего применяется старое решение;
- эмоции развиваются до высокого уровня и ведут к “аббревиатурному” поиску в признании проблемы;
- нет предыдущего опыта по проблеме и ее признание может не состояться;
- проблема является очень сложной и затрудняет ее полную идентификацию.
Интерпретация проблемы - это придание значения и определение той проблемы, которая признана. Проблема может быть определена как возможность, как кризис или как рутинная. Первый тип проблемы необходимо обнаружить и раскрыть. Второй и третий проявляются сами и требуют вмешательства менеджера. Рутинные, или повторяющиеся, проблемы относятся к категории структурированных, а возможности и кризис к неструктурированным. Соответственно каждое из них будет требовать разного типа решений:
- структурированные-програмированных;
- неструктурированные-непрограмированных.
Определение и последующие формулирование проблемы позволяют менеджеру ранжировать ее в ряду других проблем. В основу приоритизации проблемы могут быть положены следующие факторы:
- последствие проблемы;
- воздействие на организацию;
- срочность проблемы и ограничения во времени;
- лучшее использование способностей и времени руководителя;
- жизненный цикл проблемы (может ли проблема решаться сама собой или в ходе других проблем).
Изучение этих факторов позволит менеджеру определить порядок решения проблем от наиболее до наименее важных. Ранжирование является важным шагом в процессе принятия решения. Наиболее важными, как правило, становятся проблемы со следующими характеристиками:
- проблема получает сильную поддержку и давление извне в пользу ее решения (например, вышестоящее руководство настаивает на завершении работы над проектом в течении двух недель);
- проблема поддерживается ресурсами, необходимыми для ее решения (например, выделены дополнительные бюджетные средства);
- решение проблемы открывает возможность, от которой нельзя отказаться (например, выход на рынок с новой продукцией позволяет фирме улучшить конкурентные позиции).
Методы идентификации проблемы:
1. Круговая диаграмма – используется для изображения структуры проблемного поля. Диаграмма проблемного поля отвечает на вопросы: что решать? как действовать? для чего необходимы средства? когда предпринимать конкретные действия? кто этим должен заниматься?
2. Причинно – следственная диаграмма . Важным этапом анализа проблемы является структуризация причин ее появления, для чего устанавливаются причинно-следственные связи. При этом может выявиться иерархия причин, вызвавших конкретную проблему в организации (первого, второго, третьего, энного уровней), которую схематично можно представить в виде причинно-следственной диаграммы.