gifts2017

Разработка требований к автоматизированным системам

Опубликовал Александр Чавалах (chavalah) в раздел Управление - Управление проектом

Эта тема касается не только автоматизации на базе 1С, это касается любой системы автоматизации.

Сегодня я буду делиться с вами накопленным опытом в этом вопросе. В статье я хотел бы донести до читателей следующую мысль:

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

  Я разделил весь материал на четыре части.

  • Первая часть – вводная. Касается роли требований вообще. Чтобы немножко погрузиться в тему – разобраться, на что они влияют. На самом деле, они влияют на все процессы, протекающие в управлении проектами – от самоинициации до самозавершения. Поэтому я, может быть, периодически буду касаться вопросов управления проектами в целом.
  • Вторая часть – более конкретная, касается такого интересного вопроса, как предназначение документов требований. Разные есть взгляды у разработчиков на это, - одни говорят, что вообще не надо уже никакую документацию разрабатывать в принципе. Другие – наоборот,  говорят, что все нужно расписывать как можно подробнее. Это во многом спорный вопрос. Мы об этом тоже поговорим.
  • Третья часть – она будет достаточно практическая. Я попробую очень структурированно рассказать о требованиях, какие они бывают, как с ними работать, как их формулировать.
  • Четвертая часть – небольшая. О жизненном цикле требований.

Первая часть. Роль требований в управлении проектом

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

Проблема конфликта интересов внутри фирмы-заказчика

Что касается ожиданий заказчика – первое, на что тут нужно обратить внимание – это то, что конфликт интересов может быть не только между заказчиком и исполнителем. Этот конфликт интересов начинается еще и внутри самого заказчика и связан этот конфликт интересов с тем, что автоматизируется предприятие заказчика – в большинстве своем – это большая иерархически подчиненная организационная структура. И часто бывает, что, допустим, директор (руководитель предприятия заказчика) решил, что их предприятие будет автоматизироваться, и издал приказ о том, что начинается проект – озвучил какие-то громкие цели. А после этого тихо самоустранился от проекта (наблюдает за ним со стороны), убежденный в том, что его подчиненные будут честно и добросовестно трудиться над тем, чтобы достичь этих великий целей. Как показывает практика, в 98% случаев эти подчиненные ничего делать не будут, кроме того, каждый организационный уровень этой организационной структуры будет пытаться удовлетворить свои интересы (если вообще будут что-то пытаться). Руководители подразделений будут что-то делать только ради своих подразделений, а конечные сотрудники будут думать только о том, как удобнее работать им. 

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

Что с этим можно сделать?

Можно сделать три простых шага:

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

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

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

Классификация групп требований в зависимости от инициаторов

Я разделяю требования на основные четыре группы, зависящие от видов инициаторов:

  • Собственник (ТОП-менеджмент). В этом случае каждый раз, когда он будет платить деньги, будет задавать себе вопрос, за что платит. Необходимо четко контролировать ожидания собственников. Скорее всего, ему нужна информация для принятия решений.
  • Руководители отдельных структур компании (направлений, отделов и пр.). Такие проекты могут быть направлены на автоматизацию именно этих подразделений. Особое внимание следует уделить тому, кто будет принимать работы и оценивать результаты. Что думает об этом собственник (полностью ли он делегировал задачу такому руководителю?) Не скажет ли он потом: «мне это было не нужно».
  • IT-служба заказчика. В этом случае проект может быть число технологической направленности (например, интеграционный). Цели бизнеса и пр. имеют меньшее значение. Принимать такие работы тоже должна ИТ-служба.
  • Инициатива «снизу». Бывает и такое. Когда пользователи постоянно жалуются о недостатках имеющихся систем и настаивают на автоматизации. При этом человека, способного выполнять роль руководителя проекта нет, а цели непонятны. Лучше такие работы выполнять в режиме сопровождения, т.к. это не проект.

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

Составляющие удовлетворенности заказчика

Из чего может складываться путь к удовлетворенности заказчика?

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

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

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

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

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

Необходимо определить границы проекта

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

Здесь я ограничился одной такой маленькой картинкой:

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

Выхода из этой ситуации два:

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

Проблема «размытых» требований

Я хочу привести примеры формулировок поставленной задачи (я их взял из различных проектов), которые как раз и «убивают границы проекта»:

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

Это реальные формулировки из технических заданий. Автором одной из этих формулировок был я. (Это пункт насчет простого пользовательского интерфейса). Там была такая история. Директор был очень активный, конструктивный, хорошие с ним были отношения. Он сам лично активно участвовал в проекте (ничто не предвещало проблем). Он мне говорит – давайте в ТЗ один пункт и будем работать. Он еще хотел его сформулировать: «Чтобы программа была простой и имела защиту от дурака». Я все-таки, сформулировал этот пункт вот так. В результате – месяца три разработки – а потом пришлось еще работать (бесплатно, в общем-то). Я это к тому, что не надо принимать решения на эмоциональном уровне и думать, что если сейчас отношения с заказчиком такие хорошие-красивые-чудесные, то они будут такими всегда. В общем-то, ровным счетом, как и наоборот. Действовать нужно строго конструктивно.

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

Необходимо распланировать работы по проекту

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

 

Здесь ситуация такая:

Мне нравится, как сказал о планировании Эйзенхауэр – отсюда вывод какой? План – это не Библия, на которую нужно молиться или повесить его на стенку и постоянно ходить, всех тыкать о том, что план не исполняется. План нужен для того, чтобы суметь своевременно его перепланировать – только тогда он может дать полезные результаты.

Поскольку мы рассматриваем вопрос, как требования вообще влияют на проект, то - из чего складывается план работ? Очевидно, что план работ складывается:

  • из самих работ,
  • из сроков исполнения этих работ,
  • отсюда следует уже возможность оценки трудоемкости этих работ.

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

Проблемы доверия и компетенций в проектной команде

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

Из этого я вам советую запомнить одну только простую формулу:

Если мы при формулировании требований отдаем какие-то задачи на сторону аутсорсерам и думаем, что они сделают то же самое, что и те люди, которые сидят рядом с нами – которых мы знаем, то мы не правы. Это не так.

Резюмируя…

Итак, нас интересует ответ на главный вопрос:

Вторая часть. Документы требований

На этом мы переходим ко второй части и будем говорить о документах требований. 

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

Все это время у людей постоянно возникают вопросы: а те ли документы мы делаем? Не пора ли пересмотреть подходы? Почему раньше это работало, а сейчас это работать перестало (я имею в виду сами подходы)? Эти вопросы периодически возникают, даже у меня.

Какие документы требований нужны в проекте?

С годами у меня сформировалось определенное видение этого вопроса, которым я сейчас с вами и поделюсь. 

Здесь картинка разделена на две части.

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

Проблемы несоответствия содержания документов требований техническому уровню инициаторов проекта

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

 

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

Что обязательно должно содержаться в документации, формирующей требования

Вся документация, которая на проектах создается (не важно, на каких проектах), должна отвечать всего на пять вопросов:  

  • Чего требуется достичь?
  • Как это будут использовать?
  • Что нам нужно сделать для достижения цели?
  • Как разделить нашу работу на задачи?
  • Как нам потом проверить то, что мы получили?

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

По каким принципам собирать информацию в эту документацию?

Остается вопрос – как эту документацию группировать? Допустим, мы знаем ответы на эти пять вопросов, а что с этими ответами делать?  

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

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

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

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

Что дает «оформление по ГОСТу»?

Скажу два слова о ГОСТах.  

 

Когда заходит речь о программной документации, часто сотрудники заказчика говорят – зачем что-то изобретать, давно все написано в ГОСТах, все это уже 30 лет отработано, и пр. По факту – все это не совсем так. Если кто-нибудь с этим сталкивался, то ни один ГОСТ не решает проблемы с документацией.

Максимум, что он дает – это структурированный документ, и не более того.

Третья часть. Разработка требований

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

Категории классификации требований

Я для себя разделил классификацию требований на три категории – по уровню требований, по видам требований и по свойству (качеству) требований.  

 

Уровни требований. Трансформация требований

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

 

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

Виды требований. Оптимизация работ по требованиям

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

 

Какой смысл вообще группировать требования по видам?

Самое главное, что это связано с оптимизацией распределения работ потом.

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

Логичнее, что кто-то быстрее и лучше делает одни задачи, другой – другие. Кто-то разбирается, допустим, в оборудовании, кто-то совсем не разбирается. Это просто для удобства и для оптимизации работ.

Свойства и качества требований

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

  • Быть понятным,
  • конкретным,
  • проверяемым,
  • иидентифицируемым.

 

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

Зачем нужна идентифицируемость требованию – я чуть позже расскажу.

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

Как организовать работу по сбору требований?

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

 

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

Порядок проработки каждого ключевого требования

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

 

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

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

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

Заканчивается все соответственно уже фиксацией требований в виде какого-то документа (Технического задания) – не важно, как вы его назовете.

Александр Белов вообще говорит, что он никогда технического задания не делает – но он делает Протокол требований. Протокол требований – тоже документ.

Четвертая часть. Жизненный цикл требований

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

Конечно же, нужно стараться, чтобы требования были идентифицируемые. Идентификация может осуществляться по-разному. Самый простой способ – это просто сквозная нумерация (1,2,3,4…). Чтобы всегда можно было сослаться на то, что «требование № 526 не сделано». В этом случае процесс приемки-сдачи работ будет протекать гораздо более гладко и не будет таких проблем.  

 

Как решать проблемы раздувания требований?

Важный момент по управлению требованиями:

Вот этот треугольник – это границы нашего проекта. Эта картинка предназначена для понимания проблемы раздувания требований.  

 

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

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

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

А вот когда у нас начинается раздувание за счет потока пользовательских задач и там 200 человек и каждый из них что-то говорит, - то в этом всем можно просто «зашиться», потому что все, что они говорят, может вообще мало иметь отношение к тем самым ключевым требованиям. Тут какие есть варианты: можно использовать свои внутренние резервы, которые у нас должны были быть изначально на проект заложены, как раз для вот таких вот пользовательских доработок в части интерфейса, удобства и так далее. Но если эти пожелания явно уже вылезают за рамки проекта, либо у нас резерв не предусмотрен, то у нас есть два варианта. Либо мы объясняем, что мы реализацию этих пожеланий переносим за рамки проекта на какой-то уровень сопровождения, либо – в крайнем случае, когда больше ничего не остается – проще от них тогда отказаться. Это редко бывает, конечно. Можно, конечно, пытаться все реализовать, но этот процесс может быть бесконечным.  

*************

Приглашаем вас на новую конференцию INFOSTART EVENT 2016 DEVELOPER.

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Андрей Буравов (Flashill) 19.11.12 17:14
Очень полезная информация в слайде 11:
Примеры формулировок, «убивающие» границы проекта (взято из реальных проектов):
«Система должна обеспечивать поддержку эффективной системы продаж»
2.«Программа должна обладать простым пользовательским интерфейсом»
3.«Способствовать поддержанию оптимальных складских запасов»
4.«Система должна быть интегрирована со всеми системами Заказчика, имеющимися на момент запуска новой системы»

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

Также очень понравились цитаты:
Ни одна из битв не была выиграна в точном соответствии с планом, но не было и ни одной битвы, выигранной без него. (Д. Эйзенхауэр)

Необходимо запомнить: того, что нигде не записано – не существует. К этому же надо приучать и Заказчика. Аргументы «мы же об этом говорили» работать не должны. Все договоренности должны протоколироваться

Спасибо, Александр!

Кстати, где можно посмотреть (купить) полную видеозапись с конференции?
2. Александр Овсянников (_LEV_) 19.11.12 17:39
Я бы тоже не отказался посмотреть полную видеозапись.. Не всем посчастливилось там побывать.
3. Юрий Былинкин (ardn) 19.11.12 17:40
5. Ловыгин Антон (wunderland) 19.11.12 19:30
6. Модератор раздела Александр Рытов (Арчибальд) 20.11.12 11:21
Предположим, что речь ведется не о программном проекте, а о разведывательно - диверсионной операции в некой полудружественной стране. Невелика ведь разница, чего нам нужно, наладить бизнес или разладить военную машину - в любом случае требуется исследование имеющихся (бизнес) процессов, выявление ролей участников процессов, исследование связей между участниками, определение "узких мест" и, пожалуй главное, оценка адекватности информации, поставляемой системой главнокомандующему, на предмет пригодности для принятия решений. Пройдемся по презентации, под требованиями подразумевая антитребования (= стратегия/направления диверсионной подготовки).
Слайд 3 пропустим - это структурирование дальнейшего.
Слайд 4 ориентирует нас на наиболее эффектный облем, в первую очередь, верхушки заклятых друзей.
Слайд 5 напоминает о существовании противоречий между "армейскими" и "штабными". Кто работал в холдинге, тот знает.
Слайд 6: Выявить ведущие фигуры в штабе - определить их ключевые функции - на них и сосредоточиться.
Слайд 7. Оценка масштабов предполагаемой диверсии: то ли генштаб, то ли только морской флот. А может, ограничимся тыловиками (айтишниками). Отдельными военными заниматься не будем - не наш уровень.
Слайд 8 иллюстрирует сферы влияния, на которых следует сосредоточиться...
Слайды 9, 10. Не зарываться. Разведчики/диверсанты войну не выигрывают.
Слайд 11. В нашей интерпретации, будет не убийство проекта, а смена руководства ГРУ.
Слайд 15. Дружественные спецслужбы могут нам помочь, но наших задач решать не будут.
Слайд 18. В детективно-шпионской литературе постояноо попадается описание коллизий, когда герой разрывается между потребностью работать и необходимостью отчитываться.
... и так далее.
Слайды 38-40. Сбор разведданных. Ясное дело, по открытым источникам. Известно, что львиная доля разведданных в наше время как раз из них и извлекается. У меня, однако, есть сомнения в достаточности таких данных, к тому же, собираемых в весьма ограниченном временном интервале. ИМХО, без резидентуры разведка ущербна. И очень дорога.
В каких случаях будет достаточным для нас разведывательное противостояние без резидентурной сети (фикси)? Конкретнее, без учета истории и тенденций? Вероятно, это должна быть консервативная страна без особых амбиций. Наподобие Болгарии, Финляндии, торгового холдинга. А если мы имеем дело с Францией, Бразилией или с промышленной группой, модернизирующей производственные процессы?
И вот здесь абсолютно правильный подход автора - нет, к провалу проекта, скорее всего, не приведет. И ценность его не снизит - в смысле размера оплаты. Только вот много ли реальной пользы он (проект) принесет? Не станет ли одна (успешная) разведоперация помехой для операции следующей, а, возможно для хода борьбы в целом?
Думается мне, что программные проекты должны не только (даже не столько) закрывать проблемы текущие, а открывать возможности для решения проблем будущих. Такой вот размышлизм.
7. Игорь Исхаков (Ish_2) 21.11.12 10:00
(6) Выстраданная фраза :
Думается мне, что программные проекты должны не только (даже не столько) закрывать проблемы текущие, а открывать возможности для решения проблем будущих.

выдает с головой фикси , натерпевшегося от профессиональных проектантов.
В этой фразе вся соль отличия взгляда на проект "изнутри" предприятия.
Если аутсорсер действует прежде всего в своих интересах ,в рамках своего бюджета, вполне обоснованно абстрагируясь от массы других факторов, то IT-специалист предприятия абстрагироваться от текучки кадров, качества исполнителей , уровня управления , возможности послепроектной адаптации и т.д. НЕ МОЖЕТ.

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

Вот каких ответов я ждал от твоего несостоявшегося выступления на конференции.
8. Игорь Исхаков (Ish_2) 21.11.12 10:32
(0) Автору . Цитата из Эйзенхауэра показалась подозрительно не так звучащей . Проверил по Гугл.
Скорее всего в оригинале так :
При подготовке к сражению я всегда находил, что планы бесполезны, но планирование - обязательно.
9. Александр Чавалах (chavalah) 22.11.12 00:26
(8) Ish_2,
Наблюдение интересное... Вообще дословно взято из перевода книги Скотта Беркуна "Искусство управления IT-проектами".
10. Модератор раздела Александр Рытов (Арчибальд) 22.11.12 08:27
(7) Ish_2, ты уж слишком
Вот каких ответов я ждал от твоего несостоявшегося выступления на конференции.
Нету готовых ответов. Кабы были...
Как вылечить больного, если есть только симптоматика, а объективки нет? Остается только "не навреди". Могут аутсорсеры не навредить? Оно им надо?
11. Игорь Исхаков (Ish_2) 22.11.12 09:28
(10)
Могут аутсорсеры не навредить? Оно им надо?

Аусорсеры работают по часам. И это многое объясняет.
Конечно, в идеале было бы замечательно работать по результату, параметры которого четко сформулированы Исполнителем и приняты Заказчиком. И чтоб всё в бумажном протоколе ... Но где ж такое видано ?
Бумаги не напасешься.
Отсюда и появился термин "удовлетворенность Закзачика", который допускает очень широкое толкование.
Аутсорсеров можно понять : на "удовлетворенность" мы работаем по часам ( см. начало).
12. Игорь Исхаков (Ish_2) 22.11.12 09:51
(10)
Нету готовых ответов. Кабы были...


Ну ,привет.. А что ты собирался докладывать по теме :
Профессиональное управление проектами как причина провальных внедрений.

Рассказывать байки про глупых аутсорсеров ?
13. Александр Рытов (Арчибальд) 22.11.12 10:13
(11)
Отсюда и появился термин "удовлетворенность Закзачика"
Здесь (в программных проектах) нередка ситуция, когда:
- заказчик видит, что получил не то, что надо было;
- он осознает, что получил именно то, чего просил;
- вполне понятна поэтому главная претензия: внедренцы-профессионалы на то и профессионалы, чтобы дать то, что надо, а то, чего просили.
Вот тут коренится различие в классической и моей трактовках профессионализма:
- классически: зафиксировать требования менеджеров (по Задорнову - коекакеров) и исполнить их в заданном бюджете и в заданные сроки;
- надо бы: определить требования бизнеса, т.е. узкие места (в настоящем и будущем), и их разруливать. Здесь задать срок окончания не удастся, можно определить только очередность целей (последовательность проектов).
Отсюда: когда проект = этап автоматизации - все нормально. Когда проект = внедрение - это провал, ибо внедрение нельзя закончить, как и ремонт в квартире. Его можно только прекратить.
14. Михаил Ражиков (tango) 22.11.12 10:25
(12),(13) может быть "профессиональный" здесь и сейчас - наученный и "сертифицированный" в западных обучалках по западным стандартам. потому и вигвам

интересно лет через *дцать кто-нибудь расскажет о "внедрении" сапов в "рассеянские газпромы"
15. Игорь Исхаков (Ish_2) 22.11.12 12:02
(13) Ага, понятно. Чтобы повыгоднее продать свое доморощенное определение, тебе нужно чрезвычайно оглупить профессионалов своей "классической" трактовкой:
зафиксировать требования менеджеров (по Задорнову - коекакеров) и исполнить их в заданном бюджете и в заданные сроки;
Замечу, что здесь ни слова про требования бизнеса.
Скорее, перед нами трактовка непрофессионализма. Согласен , что такое поведение внедренцев практически повсеместно. Но "повсеместно" не означает "профессионально".

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

Замечательно , но замечу , что здесь ни слова про бюджет и про оплату работ профессионалов.
Скажи мне , внедренцы ( В настоящем и будущем ) должны работать за "ништяк" ?
Потому что они - "настоящие профессионалы" ?

Вообщем , слабенько как-то совсем. Не тянет на выступление на конференции.
Судя по всему , ты действительно собирался рассказывать всем байки про глупых аутсорсеров.
16. Александр Рытов (Арчибальд) 22.11.12 13:27
(15)
Вообщем , слабенько как-то совсем. Не тянет на выступление на конференции.
Если ты заметил, это и не выступление на конференции, а комментарий.
Судя по всему , ты действительно собирался рассказывать всем байки про глупых аутсорсеров.
Вот уж нигде я про глупость аутсорсеров не упоминал. Были бы глупыми - не были бы богатыми.
И это не набор баек, а напраление исследований, придуманное не мной
Прикрепленные файлы:
17. Игорь Исхаков (Ish_2) 22.11.12 16:15
(16) Хорошая ссылка. Спасибо.
Оттолкнемся теперь от статьи Ананьина, содержащей описание проектов :
Политического,Типового,Профессионального,Инновационного. ( они здесь приведены в порядке возрастания неопределенности в результатх проекта)
Так вот твое определение профессионализма
Надо бы : определить требования бизнеса, т.е. узкие места (в настоящем и будущем), и их разруливать. Здесь задать срок окончания не удастся, можно определить только очередность целей (последовательность проектов).
Отсюда: когда проект = этап автоматизации - все нормально. Когда проект = внедрение - это провал, ибо внедрение нельзя закончить, как и ремонт в квартире. Его можно только прекратить.

относится к участникам "Инновационного(!!) проекта". См. рисунок ниже.
Эк , ты замахнулся ! "Инновационного" - не больше и не меньше. Высоко летаешь.
95% внедрений это "Типовые проекты" - максимум.
Прикрепленные файлы:
18. Александр Рытов (Арчибальд) 22.11.12 16:35
(17) Ish_2, типовые внедрения неинтересны и непродуктивны (могут рассматриваться как начальный этап автоматизации). Все должно быть по-взрослому (в терминологии PAVI):
Прикрепленные файлы:
19. Игорь Исхаков (Ish_2) 22.11.12 17:15
(18) Угу. Напридумывать схем и определений "для народа" можно сколько угодно.
Например, мой "глубокий" тезис :
Муж + Жена = Успешный проект
Жена + Муж = Допустимо
Муж + Муж = Фу
Жена + Жена = Э..
разве хуже чем у Pavi ? Кто здесь Исполнитель , кто Заказчик расставьте по вкусу.
Этим и хороши для энтузиастов "проектные" теории , что допускают неисчерпаемые возможности для интерпретации и классификации отношений "Заказчик - Исполнитель".

Стремление у Pavi подать материал попроще и понагляднее похвально .
Но по существу приведенного Pavi материала сказать мне нечего.
20. Игорь Исхаков (Ish_2) 23.11.12 10:20
Ну, и напоследок.
Где место этим "проектным технологиям" , этим "стрелчкам", "кружочкам", "квадратикам" ?

Определив Исполнителя , Заказчик уже выбрал ВСЁ.
"Всё" - это узкая вилка возможных результатов проекта.

Место "проектным технологиям" там - внутри узкой вилки.
21. Svetlana_K (Svetlana_K) 28.12.14 23:42
Добрый день
Спасибо за интересную статью.
Очень важную информацию по проектам представили.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа