Информация

Последние записи

Теги


Блоги


Записи из всех блогов с тегом: проект


Моменты в управлении антикризиcными IT-проектами

Прошу прощения у подписчиков, нарыл тут у себя в архиве интересный документ.
Работа над заметками:
  • Авторская теория замены рядового менеджера от Сергея Трушкина (или почему ИИ не быстро идет в гору)
  • Педал-лохус-клан [PL] в QuakeWorld (почему в 90-е уходили из киберспорта)

    продолжается, просто не хочу их дополнять по чуть-чуть.

    Делюсь документом в режиме записи в блоге.

    К читателю
    Автор блога не обладает специализированными знаниями в классическом антикризисном менеджменте. Автор блога практически всегда был вовлечен в проекты такого рода на «плохой» стадии как управленец. Часть процесса пикирования в кризис им наблюдалась интерактивно без права решающего голоса. С точки зрения автора блога чистые методы решения проблем в проектах не могут быть успешно применены в данном типе проектов, что позволяет считать любой антикризисный проект сложным. Сложность антикризисного проекта по мнению автора блога определяется не стоимостью, не требованиями к качеству, не сроками. Как следствие содержание антикризисного проекта зависит от решений спонсора как реагировать на проблему в проекте, которая заставила считать данный проект «особым». Автор блога не претендует на универсальность примененных проектных решений и универсальность разработанных методов.
    Данная заметка подготовлена на примере антикризисного управления в проекте разработки и внедрения одной из IT-систем.

    Применяемая философия внедрения антикризисного управления в проектном опыте автора блога
    Кризис в проектном управлении – это некоторый нонсенс. Поиск нестандартных решений даже в стандартных проектных ситуациях определяет разницу в проектном подходе от подходов операционного менеджмента. Отклонение исполнения проекта от планов, в том числе и базового плана проекта не может являться причиной кризиса. Метрики исполнения проектов такие как индексы выполнения проекта по срокам или стоимости позволяют строго контролировать ход проекта, и принимать на управляющем комитете взвешенные решения о дальнейшей судьбе проекта. Существование органа с полномочиями закрыть проект без удовлетворения целей проекта является нормой, причём катастрофически не хватаемой в IT-отрасли, в проектном управлении.
    Конфликтов в целях программы проектов и проекта, как и конфликтов по бюджету между портфелем проектов и проектом не должно быть в управлении проектами. Но к сожалению, согласованность данных параметров не определяется напрямую, и с точки зрения автора блога также не может быть определена с помощью компетентностей руководителя проекта на данном этапе зрелости проектного управления в целом.
    Автор блога в целях лучшего понимания прикладных выводов, изложенных далее в записи предлагает следующие определения:
    Пикирование в кризис – потеря информации о текущем ходе проекта в принятых интегральных характеристиках исполнения проекта.
    Кризис в проекте – ситуация закрытия проекта, инициированного любым уполномоченным органом неофициально. Отсутствие официального решения по проекту с одновременной эскалацией означает, что фактического управления проектом не осуществлялось и не осуществляется.
    Обоснование сложности IT-проекта-основания.
    Организация-заказчик
    Наименование организации-заказчика
    Организацией-заказчиком проекта, рассматриваемого в записи, являлось дочернее предприятие крупной Госкорпорации.
    Профиль организации-заказчика
    Создано в 90-00-х годах с целью выделения IT-технологического стека в отдельный контур управления.
    Ситуация
    Заинтересованные стороны
  • Госкопорация
  • Заказчик
  • Исполнитель
    Время осуществления проекта: 10-е гды
    Место осуществления проекта: Российская Федерация
    Ситуации антикризисного управления
  • Урок «Признать кризис – это не просто»
  • Урок «Облегченный сбор требований»
  • Урок «Адаптация под реалии»
  • Урок «Вызов ответственности»
  • Урок «Истерика»
  • Урок «Альтернативная стоимость»
  • Урок «Переговоры»
  • Урок «Brainstorming»
  • Урок «Неопределенность»
  • Урок «Потеря фокуса»
  • Урок «Страх»
  • Урок «Все не могут быть правы»
  • Урок «Критический путь»
  • Урок «Официальная переписка»
  • Урок «Дружба»
  • Урок «Доверие»
  • Урок «Принцип аналогий»
  • Урок «Растущая стоимость»
  • Урок «Живой регламент»
  • Урок «Agile-этап»
  • Урок «Приемочные испытания»
  • Урок «Гарантийная поддержка»


    Урок 1. Признать кризис – это не просто
    Обычно ситуация обнаружения кризиса в проекте означает одновременное прозрение всех заинтересованных лиц проекта, что проект необходимо закрыть. Это ведет к формальному запуску процедуры завершения проекта и фиксации убытков всех заинтересованных сторон.
    Именно одномоментность признания всеми заинтересованными лицами проекта невозможности успешного завершения проекта в заданных ограничениях и является основным реактивным фактором в определении проектов, рассматриваемых автором блога.
    Почему не предупредили подобную ситуацию? Данный вопрос является ключевым. «Вчера» проект был, а «сегодня» не существует мер по его продолжению!
    На вопрос необходимо дать ответ. Доверие к отчётности по проекту, доверие к управляющим органам проекта исчезло.
    Урок 2. Облегченный сбор требований
    Т.к. в проекте неожиданно исчезает потенция в получении результата, то оснований для продолжения проекта нет. И здесь возникает первый парадокс иерархии проектного управления: хотя проект был согласован и по бюджету в портфеле проектов, и по целям в программах сторон.
    Проект вдруг приобретает дополнительный политический вес.
    С точки зрения автора блога и по его опыту – ситуация стандартна в проектном управлении. Данная ситуация возникает всегда в конкурентной среде при отсутствии механизма согласования портфелей и программ проектов между исполнителем и заказчиком.
    Возможными источниками неформального согласования подобного рода автор блога считает правильным пренебречь.
    В этот момент необходимо провести анализ внезапно появившегося дополнительного веса проекта. Вопросы, на которые необходимо дать быстрый качественный ответ очевидны:
  • Насколько велики потери в репутации?
  • Можно ли окупить дополнительные инвестиции в проект на данной стадии?
  • Как повлияет исключение проекта из программы?
    Перефразируя, получаем «Проект умер. Да здравствует проект!»
    Возникает необходимость в сборе требований, требований к проектному решению в режиме организационного коллапса в проекте. По сути требуется повторение обследования в режиме уже случившей неудачи проекта.
    Урок 3. Адаптация под реалии
    Автор блога не знает иных механизмов «моментального» согласования портфелей и программ проектов кроме концептуального реинжиниринга решения. Здесь и далее под концептуальным реинжинирингом решения автор понимает аналитическую работу над парадигмой признания результатов проекта успешными. Именно разработка понимания приемки результатов проекта, и только оно (понимание) накладывает ограничения на новый проект. Таким образом с точки зрения автора блога у проектов данного рода смещается акцент с разрабатываемого решения на механизмы его валидации и верификации. Здесь и далее под валидацией решения автор блога понимает функциональность разрабатываемого IT-решения, а под верификацией решения понимается строгое соответствие создания решения требованиям по структуре продукта. Только поименованный и описанный в парадигме приемки алгоритм признания успешности проекта может помочь в подобный момент. Это можно поименовать вторым парадоксом проектного управления: нельзя разработать алгоритм признания успешности проекта, если в проекте не случился кризис.
    Именно кризис в проекте интенсифицирует процессы сбора требований. Происходящая адаптация всех заинтересованных сторон проекта под текущие реалии форсируется именно потерей эскалационных механизмов в проекте. Эскалационные механизмы исчезли в момент неформального закрытия проекта. Любое изменение в проекте на этой стадии обязано быть согласовано и принято. С этого момента управление изменениями становится строго формализованным на базе парадигмы приёмки.
    Урок 4. Вызов ответственности
    Отсутствие процессов мониторинга и контроля пирамиды ограничений проекта «содержание, качество, сроки, бюджет», разработанной на момент старта проекта органично привело к конфликту. При этом неформальное желание закрыть проект может быть оформлено по-разному, но суть конфликта всегда одна: уточнить ответственных за сложившийся неуспех проекта. Интересно, что заинтересованную сторону, инициировавшую конфликт, завершение проекта уже не интересует. Проработав и изучив варианты для своих портфеля и программ проекта эта заинтересованная сторона оказалась первой, кто признал фатальность успеха именно данного проекта для своей организации в целом. Ее цель в данном конфликте сделать фатальным успех проекта для всех заинтересованных сторон.
    Урок 5. Истерика
    Важным составляющим конфликта в описанной ситуации является признание всеми заинтересованными сторонами, что это пик возможных эскалаций в проекте. Проект стал системообразующим для заинтересованных сторон. Бюджет, сроки, качество и содержание проекта приносятся в жертву возможности спасти репутацию.
    Истеричность решений на данном этапе достигает максимума. Выдавать желаемое за действительное на данной стадии проекта становится парадигмой проекта.
    Урок 6. Альтернативная стоимость
    По мнению автора блога, самым важным аспектом при принятии решения о выходе из проекта должна быть альтернативная стоимость. Провести тщательный анализ альтернатив в подобных ситуациях возможно, но лица принимающие решения в организациях участниках проекта находятся в цейтноте. Конфликт не прогнозировался. Конфликт воспринимается как форс-мажор. Стоимостной анализ решений с точки зрения принимающих решения лиц в текущей проектной ситуации невозможен. К альтернативной стоимости заинтересованные лица вернутся позже.
    Урок 7. Переговоры
    Заинтересованные стороны входят в затяжной цикл переговоров. Цель данных переговоров оценить политический вес проекта. Прямое вычисление данного веса осложненно возможным поведением всех сторон переговоров. С повестки дня в ходе переговоров уходит персональная ответственность членов команды проекта. Стороны приходят к соглашению, что проект должен быть продолжен. И здесь можно отметить третий парадокс проектного управления: максимально возможная политическая ангажированность при принятии решения о невозможности закрытии проекта приводит к максимально возможному уменьшению политики в дальнейшем ходе проекта.
    Урок 8. Мозговой штурм
    Одного организационного решения продолжать проект мало. Стороны начинают делиться своим проектным багажом. Отличительной особенностью данного мозгового штурма является то, что стороны с удивлением обнаруживают те требования на разрабатываемое проектное решение, которые только подчёркивают бедственную ситуацию в проекте.
    Урок 9. Неопределенность
    В этот момент приходит понимание, что проект закрыт. И открыт новый проект. Проектная неопределенность, как и эскалация достигает своего пика. Проектных материалов может быть накоплено очень много, но к их анализу команда проекта вернется только после успешного завершения нового проекта.
    Урок 10. Потеря фокуса
    Первым, очевидным и единственным выводом после признания ужасающей проектной неопределенности является факт, что потерян фокус в проекте. Здесь и далее под фокусом проекта автор блога понимает не только цели проекта, но и бизнес-выгоду владельца продукта (решение проблемы Заказчика). Формирование нового фокуса проекта становится основной целью команды.
    Урок 11. Страх
    Прошёл эпатаж эскалаций. Ушло дополнительное время на переговоры. Стороны всего лишь договорились о намерениях нового проекта. План отсутствует. Зафиксировано неудачное завершение проекта.
    Урок 12. Все не могут быть правы
    С точки зрения автора блога в этот момент должно прийти признание, что только компромисс может являться методом решения проблемы. Стороны определяют кто чем жертвует при инициации нового проекта. Формируется новые параметры проекта в части сроков, стоимости, качества и содержания. Алгоритм формирования параметров ложится парадигму приемки.
    Урок 13. Критический путь
    Важным аспектом принимаемой парадигмы приемки результатов проекта является отношение к критическому пути (цепь задач максимальной длительности)проекта. Для проектов данного рода по мнению автора блога не план является основой для вычисления критического пути, а критический путь является основой для планов и целей проекта. Существование подобного критического пути сразу не очевидно. Но именно его разработкой и занята команда проекта в переходный период.
    Урок 14. Официальная переписка
    Отдельным пунктом автор блога хочет отметить официальную переписку. Несмотря на исчезновение в проекте политических течений эскалация в проекте ещё долго оставляет свой след в официальной переписке по проекту. Автор блога хочет отметить, что по его экспертному мнению официальная переписка в таких ситуациях не бесполезна. Единственное, что заинтересованные стороны не должны на нее тратить избыточные проектные ресурсы.
    Урок 15. Дружба
    Разработка парадигмы приёмки начинается, как только очерчены критерии компромисса. Здесь и только здесь конфликт заканчивается. Появляется надежда на возможную успешность нового проекта.
    Урок 16. Доверие
    Не все договоренности, очерченные в поисках компромисса можно изложить в плане управления проектом. Основная их часть останется в неформальной переписке. Доверие, вернувшееся в проект может быть опять потеряно. Но по мнению автора блога управлять подобным риском в проектах данного рода избыточно.
    Урок 17. Принцип аналогий
    Управление проектами бизнес-изменений по мнению автора блога всегда основывается на накопленной Исполнителем экспертизе успешных проектов подобного рода. С этой стороны стартующий проект изменения бизнес-процессов организации-заказчика для внедрения IT-решения выглядит «легкой прогулкой». Возможные паттерны плохих процессов, паттерны целевых хороших процессов и готовые паттерны изменений в активе организации-исполнителя заставляют относится к подобному роду проектов как проекту внедрения тиражного решения. Основная беда данного подхода неожиданно появляющееся сопротивление ключевых пользователей разработанного продукта в целом. Проект по изменению бизнес-процесса начинает тонуть в изменениях проекта создания IT-продукта. Этот момент знаменует коллапс тиражного подхода. Время на согласование целевой картины устремляется в бесконечность.
    Урок 18. Растущая стоимость
    Оценка стоимости проекта изменений с учетом небольшого количества итераций на согласование оказывается некорректной. И качественно проведенное обследование, и проверенные практикой готовые предложения по целевой картине основного бизнес-процесса наталкиваются на невозможность выработать общий консенсус по топологии организационных изменений. В этих случаях каждое рабочее совещание оформляется в лучшем случае протоколом разногласий, а нередко и решение о повторе обследования в части процессов.
    Урок 19. Живой регламент
    Качественно иной подход демонстрируется при наличии ИТ-системы поддержки целевых бизнес-процессов. Каждое предложение по модификации бизнес-процессов становится качественно измеримым в параметрах работы конечных пользователей системы. Целевой бизнес-процесс становится понятным пользователю не на основе нотации блок-схемы, а на основе демонстрируемых примеров работы на системе.
    Урок 20. Agile-этап
    И здесь появляется вся мощность гибких методологий. Быстро создать работающий (!) продукт в части бизнес процессов для демонстрации и тестирвоания конечными пользователями концепта конечного продукта иным образом не решит проблему не вылететь за жесткий дедлайн.
    Урок 21. Приемочные испытания
    Поэтому и получается, что приемочные испытания пройдут в одно касание, Журнал Опытной Эксплуатации будет невелик и в конечном счёт решенная задача позволит окончить проект создания IT-продукта успешно, важным останется формализовать регламенты гарантии и сопровождения.
    Урок 22. Гарантийная поддержка
    И всё же всё не удастся выполнить даже за срок гарантийной поддержки, и конечный продукт не будет иметь две-три фишечки, который хотелось иметь на момент коммерческого предложения, контракта и Agile-этапа


    РЕЗЮМЕ

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

  • Инициация антикризисного проекта
  • Пирамида власти против пирамиды мотивации
  • Измена целям Заказчика в пользу решения его проблемы, инициировавшей изначальный проект
  • Кооперация против конфронтации
  • От AS IS к TO BE или управление подпроектом бизнес-изменений для внедрения версии IT-продукта
  • Гибкие методы и необходимость в WYSIWYG


  • 3 причины не верить почасовой ставке

    Блог: Gandjustas' blog

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

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

    1. Почасовая ставка не определяет стоимость проекта

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

    Это вполне нормально. Алистер Коберн в статье “Магия числа ПИ для руководителей проектов” вывел простую зависимость - если команда новая и проект новый, то оценки нужно умножать на Пи в квадате, что примерно равно 9,87. Опытная команда, которая уже сделала аналогичные проекты, может сделать проект с трудозатратами в 10 раз меньше, чем неопытная. Кроме того, если у компании есть наработки, решающие задачи клиента, то оценка также может быть снижена.

    Так что разница в оценках в 3-5 раз - вполне ожидаема. Почасовая ставка меньше влияет на стоимость проекта.

    2. Почасовая ставка снижает качество

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

    читать дальше...
    автор: gandjustas добавлено: 05 дек 16 просмотры: 2089, комментарии: 3



    Успех проекта SharePoint, где он?

    Блог: Gandjustas' blog

    Есть статистика, которая говорит, что более половины SharePoint проектов неуспешны (смотреть тут). С точки зрения бизнеса успешных проектов еще меньше, так как затраты оказываются выше, чем экономический эффект.

    Проблема

    Многие проекты SharePoint фактически ведутся по процессам разработки программного обеспечения. Все процессы разработки ставят целью разработку нового или доработку существующего ПО. Основные KPI для такого проекта – сроки, функциональный объем и бюджет. Еще говорят о качестве, но качество померить сложно и оно как-то выпадает из основных характеристик.

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

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

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

    Как добиться успеха

    В первую очередь надо фокусироваться не на поставке функционала, а на увеличении value от внедрения. Причем этот самый value надо не просто определить, а измерять. Проект сч...

    читать дальше...
    автор: gandjustas добавлено: 10 окт 16 просмотры: 2338, комментарии: 0



    Как поставщики решений SharePoint обманывают заказчиков

    Блог: Gandjustas' blog

    На днях получит вот такой коммент в обсуждении на Хабрахабре:

    Государственный университет в регионе N хочет себе СЭД, пользователей на 100. Кроме СЭД хочет простенький портал, телефонную книгу, новости, календарики.
    На Sharepoint Server денег тратить не хочется, да и нет необходимости — рейтинги, социальные сети, политики хранения контента не в почете у сотрудников.
    Поэтому решили купить СЭД на Foundation, заплатив только за СЭД-надстройку (будем считать что лицензионные права на Foundation у них уже есть).


    За 2-3 года документов скопилось около 60-80 тыс. (по всем группам). По ним нужно, в самом простейшем случае:
    а) осуществлять быстрый и легко настраиваемый поиск (по конкретным атрибутам и без управляемых метаданных) по любым элементам и с учетом прав
    б) быстро искать и исполнять задачи. задач при этом становится = (кол-во документов * 5)

    Если знаете способ реализовать это на Foundation «изкаропки», пожалуйста, расскажите, очень интересно.

    Исходный пост и обсуждение можете почитать по ссылке: http://habrahabr.ru/post/210844/#comment_7260770

    Используя SharePoint Server, даже версии Standard, можно настроить быстрый и удобный поиск по документам и задачам. Это даже не потребует программирования, достаточно будет за день-два выполнить настройку поисковых представлений.

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

    читать дальше...
    автор: gandjustas добавлено: 06 окт 16 просмотры: 2212, комментарии: 0



    Как проектному менеджеру провалить продажу проекта

    Блог: Gandjustas' blog

    В статье речь пойдет о типовых ИТшных проектах, которые продают большинство компаний-интераторов\аутсорсеров\разработчиков.

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

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

    Способ №1

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

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

    И это при том, что скорость в современном мире – один из важных факторов дифференциации от конкурентов.

    Способ №2

    Следу...

    читать дальше...
    автор: gandjustas добавлено: 04 июл 16 просмотры: 1025, комментарии: 0



    Алиса в стране ИТ-проектов

    Блог: Gandjustas' blog
    Недавно наткнулся на сборник цитат из произведений Льюиса Кэрролла про Алису. Очень удивился, как некоторые цитаты описывают что происходит в ИТ-проектах.

     

    Про заказчиков

    Шляпных дел мастеров я уже видела. Мартовский Заяц, по-моему, куда интереснее. К тому же сейчас май — возможно, он уже немножко пришёл в себя.
    — Ничего не поделаешь, — возразил Кот. — Все мы здесь не в своем уме — и ты, и я!
    — Откуда вы знаете, что я не в своем уме? — спросила Алиса.
    — Конечно, не в своем, — ответил Кот. — Иначе как бы ты здесь оказалась?

    Про анализ требований

    Не грусти. Рано или поздно все станет понятно, все станет на свои места и выстроится в единую красивую схему, как кружева. Станет понятно, зачем все было нужно, потому что все будет правильно.
    Не все ли равно, о чем спрашивать, если ответа все равно не получишь, правда?
    — Как мне попасть в дом? – повторила Алиса громче.
    — А стоит ли туда попадать? – сказал Лягушонок. – Вот в чем вопрос.
    – Ты что, не знаешь, что такое «это»?
    – Я прекрасно знаю, что такое «это», когда я его нахожу.
    Всё страньше и страньше! Всё чудесатее и чудесатее! Всё любопытственнее и любопытственнее! Всё страннее и страннее! Всё чудесится и чудесится!

    Про написание Технического Задания

    Я видала такую чепуху, по сравнению с которой эта чепуха — толковый словарь.
    Как она ни пыталась, она не могла найти тут ни тени смысла, хотя все слова были ей совершенно понятны.
    Если в мире все бессмысленно, — сказала Алиса, — что меша...
    читать дальше...
    автор: gandjustas добавлено: 23 июн 16 просмотры: 1375, комментарии: 1



    Как процесс валидации поможет сделать UX дизайн разумнее

    Валидация – это способ, позволяющий подойти к процессу UX (User Experience) дизайна концептуально и применить необходимые техники и методы на каждом шаге. В этой статье мы расскажем о том, как применить эту гибкую методологию, чтобы улучшить UX дизайн. Зачем нужна методология? Прежде всего ответим на вопрос: зачем вообще нужна методология, когда мы говорим о дизайне? […]

    Запись Как процесс валидации поможет сделать UX дизайн разумнее впервые появилась Платформа Качества.

    читать дальше...
    автор: krukovskiy добавлено: 10 сен 15 просмотры: 1685, комментарии: 0



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

    Для чего? Всегда интересно учиться чему-то новому. Это полезно. Вдвойне хорошо, если во время своего обучения ты еще можешь принести пользу другим. А если при этом ты помогаешь благотворительному фонду, который дарит радость детям, то вечер точно прошел не зря. В этот раз участники клуба сервис-дизайна помогали Фонду «Ключ от детской». На очередной встрече, которая […]

    Запись Кейс. Использование инструмента Blueprint для повышения качества сервисов. впервые появилась Платформа Качества.

    читать дальше...
    автор: krukovskiy добавлено: 02 авг 15 просмотры: 1162, комментарии: 0



    Как проектному менеджеру провалить продажу проекта

    Блог: Gandjustas' blog

    В статье речь пойдет о типовых ИТшных проектах, которые продают большинство компаний-интераторов\аутсорсеров\разработчиков.

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

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

    Способ №1

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

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

    И это при том, что скорость в современном мире – один из важных факторов дифференциации от конкурентов.

    Способ №2

    Следу...

    читать дальше...
    автор: gandjustas добавлено: 07 июн 15 просмотры: 1077, комментарии: 0



    Алиса в стране ИТ-проектов

    Блог: Gandjustas' blog
    Недавно наткнулся на сборник цитат из произведений Льюиса Кэрролла про Алису. Очень удивился, как некоторые цитаты описывают что происходит в ИТ-проектах.

     

    Про заказчиков

    Шляпных дел мастеров я уже видела. Мартовский Заяц, по-моему, куда интереснее. К тому же сейчас май — возможно, он уже немножко пришёл в себя.
    — Ничего не поделаешь, — возразил Кот. — Все мы здесь не в своем уме — и ты, и я!
    — Откуда вы знаете, что я не в своем уме? — спросила Алиса.
    — Конечно, не в своем, — ответил Кот. — Иначе как бы ты здесь оказалась?

    Про анализ требований

    Не грусти. Рано или поздно все станет понятно, все станет на свои места и выстроится в единую красивую схему, как кружева. Станет понятно, зачем все было нужно, потому что все будет правильно.
    Не все ли равно, о чем спрашивать, если ответа все равно не получишь, правда?
    — Как мне попасть в дом? – повторила Алиса громче.
    — А стоит ли туда попадать? – сказал Лягушонок. – Вот в чем вопрос.
    – Ты что, не знаешь, что такое «это»?
    – Я прекрасно знаю, что такое «это», когда я его нахожу.
    Всё страньше и страньше! Всё чудесатее и чудесатее! Всё любопытственнее и любопытственнее! Всё страннее и страннее! Всё чудесится и чудесится!

    Про написание Технического Задания

    Я видала такую чепуху, по сравнению с которой эта чепуха — толковый словарь.
    Как она ни пыталась, она не могла найти тут ни тени смысла, хотя все слова были ей совершенно понятны.
    Если в мире все бессмысленно, — сказала Алиса, — что меша...
    читать дальше...
    автор: gandjustas добавлено: 19 фев 15 просмотры: 2036, комментарии: 0


    предыдущие записи