[Тимур]

Есть ряд существенных проблем

- На практике большая часть менеджеров имеет те или иные проблемы с письменной формой общения

Это как? Читать писать не умеют? Нафига такие нужны.

Все остальное можно привить. Это реально, хотя и не так быстро. Зато плюсы больше.

 

Допустим, ты прав.

Тогда объясни зачем в методике SCRUM жестко заложены ежедневные совещания и совещания в начале спринта?

https://ru.wikipedia.org/wiki/Scrum

[Sergey Gilfanov]

Тогда объясни зачем в методике SCRUM жестко заложены ежедневные совещания и совещания в начале спринта?

В первых же найденных ссылках:

The daily scrum meeting is not used as a problem-solving or issue resolution meeting.

В общем - оно скорее точка фиксации или 'heartbeat' происходящего, чем что-то еще.

[Тимур]

В общем - оно скорее точка фиксации или 'heartbeat' происходящего, чем что-то еще.

 

Точка фиксации "чтобы что"(с)?

Почему не ограничиться рассылкой?

[SergoINFOLAN]

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

[LionSprings]

Тогда объясни зачем

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

[Sergey Gilfanov]

Точка фиксации "чтобы что"(с)?

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

 

Почему не ограничиться рассылкой?

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

[Тимур]

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

 

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

Но мой опыт говорит, что только на письмо надеяться нельзя. Людей которые могут _успешно_ решать вопросы в переписке что-то типа 10%. С остальными нужно общаться. Со многими и общения мало - нужно картиночки показывать, еще какие-то штуки делать...

 

Тогда объясни зачем

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

 

То есть скрам не имеет отношения к управления проектами? Аррригинально...

[Syzygy]

По моему у Тимура проблемы или нет вовсе, или она в людях.

У Тимура проблема в Тимуре, на самом деле. Не умеет делегировать полномочия и подход к персоналу скорее кампанейский, а не руководительский.

[Тимур]

По моему у Тимура проблемы или нет вовсе, или она в людях.

У Тимура проблема в Тимуре, на самом деле. Не умеет делегировать полномочия и подход к персоналу скорее кампанейский, а не руководительский.

 

Уже отвечал :-)

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

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

 

Еще вопросы? :-))))

[Syzygy]

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

[Тимур]

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

 

Слушай, вот тут меня все тыкают SMARTом. Все вот говорят - проект не проект, пока нет метрика и баста.

Однако по факту за весь наш 14 страничный разговор никто пока еще этим самым смартом не блестнул.

 

Может ты попробуешь? Сформулируй пожалуйста в измеримых терминах - что значит "умеет делегировать полномочия".

Ну... просто чтобы я знал к каким показателям нужно стремиться :-)))

 

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

Это говорит о том, что делегирование есть или не говорит? ;-)

[Sergey Gilfanov]

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

Но мой опыт говорит, что только на письмо надеяться нельзя. Людей которые могут _успешно_ решать вопросы в переписке что-то типа 10%. С остальными нужно общаться. Со многими и общения мало - нужно картиночки показывать, еще какие-то штуки делать...

Тут есть приятная особенность - не все участвующие должны хорошо развитыми навыками подобной работы обладать. Достаточно одного на n-ное количество человек. Который и пообщается (тогда, когда тому сотруднику удобно) и вытянет из этого сотрудника, что он имеет в виду и потом отредактирует и дополнит соответствующие документы. Ну и задачи внутри трекера раскидает. Есть подозрение, что когда технологии были еще бумажно-телефонные, эта должность называлась 'личный секретарь руководителя'. Как сейчас оно называется - не знаю. Вполне возможна еще мутация до 'секретарь отдела', а не конкретного человека.

[Syzygy]

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

 

Это говорит о том, что делегирование есть или не говорит? ;-)

Не знаю конкретно вашу ситуацию, поэтому возможны два варианта:

1) Ты так хорошо распределил задачи, что тебя дёргают только по нужным делам

2) Ты настолько херовый руководитель, что тебя не дёргают, ибо знают, что толка будет ноль.

 

Как сейчас оно называется - не знаю.

Так и называется, "личный помощник".

[Тимур]

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

 

Я с тобой согласен. Запятая толстое НО.

Ты будешь смеяться, но я уже пятый год не могу закрыть эту вакансию :-)))

На этой позиции с разной степени неуспешности у меня успело провалиться четыре человека.

 

Сейчас вот - чуть из кризиса подвыпутаемся и я попробую сделать пятую попытку. :-)))

[Тимур]

Нельзя представить в измеримых терминах задачи.

 

И да и нет.

- Я уверен, что есть гуру смарта, которые бы крякнув осилили бы и такой квест

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

 

 

 

Это говорит о том, что делегирование есть или не говорит? ;-)

Не знаю конкретно вашу ситуацию, поэтому возможны два варианта:

1) Ты так хорошо распределил задачи, что тебя дёргают только по нужным делам

2) Ты настолько херовый руководитель, что тебя не дёргают, ибо знают, что толка будет ноль.

 

Все просто.

Операционные задачи по базовым бизнес-процессам давно распределены и уже неплохо устаканились.

 

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

[Syzygy]

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

Вообще-то это обязанности владельцев фирмы и высшего руководство. Кому ты их собрался делегировать?

[Sergey Gilfanov]

Так и называется, "личный помощник".

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

[Syzygy]

Ты путаешь понятия. Секретари не делают всего того, что ты написал.

[Тимур]

Кажется пора потихоньку переползать к стратегическому слою. Но сначала очередное отступление :-)

 

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

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

 

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

 

Тут у нас с Прохожим некое разночтение. Он говорит, что не нужно мол плодить сущностей. А разве вычленять их не полезно?

 

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

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

 

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

 

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

 

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

[Тимур]

Стратегический уровень

 

Вы уж извините меня. Я и до текущего-то момента не был особенно внятен. По крайней мере большинство комментариев свелось к тезису "Ты ничего не знаешь, Джон Сноу" (с)

 

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

 

Начнем с того, что я уже понимаю про стратегический уровень

 

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

 

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

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

- утрата перспективы и понимания ритма длинных проектов (нет понимания кто, что, зачем делает и делает ли вообще)

как следствие первых двух можно констатировать существенные проблемы с управляемостью

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

 

 

От проблемы "неопредеделенность в целях проектов" есть производные проблемы

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

- отсутствуют стабильные долгосрочные приоритеты (так как приходится действовать в условиях объективной неопределенностью в целях)

- проблемы с наличием внутреннего заказчика. Не очень понятно кто заказчик и почему. И что из этого вытекает

 

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

 

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

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

- утрата перспективы влияет на скорость и качество внедрения (или не внедряемся, или тонем в бессмысленных доделках)

 

 

От проблемы "система не прозрачна" есть производные проблемы

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

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

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

 

 

 

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

 

 

 

Но одно дело, осознавать наличие проблемы, а совсем другое дело знать как ее решить.

 

Ок. Но теперь добавим в систему существенные ограничения. Давайте исходить из того, что на высшее руководство компании надежда плоха. Ну так уж получилось, что нет тут людей, которые могут взять на себя тяжкую ношу стратегического управления. Взять хотя бы к примеру обыкновенного меня. Ну все уже поняли, что я не стратег. Нанять стратегов? Нет денег :-)

 

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

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

 

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

[Тимур]

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

 

Итак, по мотивам всех этих стратегических страданий, я в общих чертах понял некую шуку. Не факт, что она решит стратегические проблемы, но... она по крайней мере выглядит прикольно. Как говорил Джонни Роттен из ВиА Sex Pistols "Don't know what I want, but I know how to get it. I wanna destroy the passer by cos I wanna be anarchy!"

 

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

 

Тактический уровень отрабатывается любым таск-треккером.

 

Оперативный уровень нужно сделать отдельной системой, куда из таск-треккера экстрагируются исключительно задачи которые нужно молотить мне и сейчас - "я ответственный"+"в работе". Тогда тасков будет обозримое количество. Как следствие менеджер не будет бояться туда заглядывать. Дальше нужен гибрид из перрсонального таск-менеджера и группового календаря. Что-то типа как в гуглетаск + гуглкалендарь, но потолковее.

 

 

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

 

Конкретно на конфлюэнц я посмотрел... ну эта... оно и платное и могло бы быть посимпатичней... Может нужна другая среда - какой-нибудь вордпресс... или фейсбук :-)) короче мы пока толком не копали

 

 

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

[Тимур]

Поехали.

 

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

 

 

Во-первых, мы можем пойти по пути Agile. Сходу бы я стырил следующие идеи (копирую из вики)

> работающий продукт важнее исчерпывающей документации;

> удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

> приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

> частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

> тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

> рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

 

 

Во-первых начительная часть наших проектов это и так разработка или допилы софта. И заказчик внутренний достаточно близок. Так что должно получиться.

 

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

 

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

- изучаем ситуацию и примерно понимаем чего хотим изменить

- придумываем метод реализации

- делаем

- проверяем получилось ли добиться бизне-результатов

 

И так крутим до бесконечности. То есть это процесс.

 

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

 

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

 

Тогда функционал системы может быть например такой.

 

- создаем какую-нибудь хрень типа реестр проблем (название/описание/теги)

- прикручиваем к этим проблемам голосовалку

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

 

Таким образом мы получаем ранжированный по приоритетности список проблем.

 

Дальше раз в квартал мы смотрим на этот список и делаем у проблемы статус

- проблема понятна, случается редко, пока бъем болт

- проблема понятна, существенна, нуждается в решении

- проблема решается - открыт такой-то проект, с такими-то ответственными, ожидаем такие-то сроки реализации

- проблема предположительно запилена - проверяйте - не должно повторяться

 

 

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

 

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

 

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

 

 

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

 

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

 

 

Собственно говоря как мы живем сейчас. У нас есть такая практика - квартальные сборы. Раз в квартал мы собираемся отделами (по собранию на отдел), смотрим какие зарегистрированы косяки, думаем что с этим можно системно сделать. Если есть идеи как пропатчить - забиваем таск в таск-треккер. На следующем собрании опрашиваем сотрудников - ну чего мол как? В половине случае выясняется, что проблема успешно решена, а в другой половине случаев выясняется, что сделано что-то не то. Тогда таск перезагружаем, в новой формулировке. Это одна из немногих реально работающих практик и она приносит пользу. Другое дело, что мы опять же теряем перспективу. Никто уже не помнит - какое количество херни удалось разрулить за все это время.

 

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

[Тимур]

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

 

Нам нужна карта.

 

Тут я даже не очень понимаю, что это такое. В голове крутится что-то типа карты из HeroesM&M...

 

Допустим, у нас есть цель мы хотим поднять продажи за год на 20%. Например мы решили, что 10% нарежем должны нарезать в старых районах, а еще 10% в новых. Дальше мы понимаем, что для того чтобы в старых районах поднять продажи на 10% нам нужно, увеличить количество расклейщиков листовок + попросить монтажников при подключнии оставлять всякие прикольные промоштуки и т.л. Ну не важно. Короче вот мы спланировали нашу деятельность в общих чертах. Забили в тактическую систему проекты и эпик-таски.

 

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

- роадмап (последовательность и состав эпик тасков, кто на кого и как влияет)

- ответственные по таскам

- актуальное состояние (какие эпики взяты и когда (не просто таскдан, но и таскдан в 1м квартале))

- план (когда собираемся взять таск)

 

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

 

Тут возможны варианты

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

- можно пытаться строить из системы аутоматично

 

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

 

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

 

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

 

Это опять же к вопросу о заказчике

 

 

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

 

 

Короче не понимаю как это реализовывать. Теоретически многоуважаемый олл может сказать - yo nigga - не парься - то что ты говоришь это похоже на такой-то плагин к вики движку - вот держи сцылку. Было бы мило, конечно (Я кажется уже говорил, что устал от девелопмента?)

 

 

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

 

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

 

 

 

Короче - если мы поднимем что-то такое. То мы существенно выбъем проблемы связанные с утратой ориентиров

цитирую

- отсутствуют стабильные долгосрочные приоритеты (так как приходится действовать в условиях объективной неопределенностью в целях)

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

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

- утрата перспективы влияет на скорость и качество внедрения (или не внедряемся, или тонем в бессмысленных доделках)

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

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

 

 

Ну... я по крайней мере на это надеюсь 8-)

[Прохожий]

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

 

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

 

Если же объяснить устно (но обязательно сопровождая письменным материалом), то восприятие идет гораздо правильнее.

Прекрасная иллюстрация. Сразу для нескольких моментов.

 

Вариант А. Написано нормально и достаточно. Большинству людей тупо не достает самодисциплины чтобы вникать, им проще самим себе объяснить что непонятно, и вообще - плохо воспринимается письменный текст. Поверь, что если бы у них по итогам был экзамен с ценой сдачи/не сдачи в один месячный оклад - то внезапно выяснилось бы, что прекрасно они умеют письменное воспринимать. В этом смысле "инструктор" играет ту же роль, что преподаватель на платных курсах. Никто не мешает тебе самому выучить любой язык - кроме лени. И ты платишь деньги за то, чтобы регулярно под руководством инструктора делать то, что ты прекрасно мог бы делать сам бесплатно ;)

 

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

 

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

 

Мы так и сделали. Под парадигмой "если информации нет в трекере - значит её нет нигде и никогда не было".

Интересно, сколько времени и нервов это заняло?

 

Это уже путь к хитрым и витиеватым припискам.

Это не так опасно, как кажется. Искажения есть всегда, но! Документированные в системе искажения - это риски последующего обривания яиц. А искажения в трепе - это риски максимум разборок голосом с воплями "вы меня не так поняли". Первое, понятное дело, предпочтительнее.

 

Просто я хочу сказать, что сущности в чем-то схожие но разные. И управляться с ними нужно по разному.

 

Не согласен, что по разному?

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

 

То есть скрам не имеет отношения к управления проектами? Аррригинально...

Таки да, не имеет. Что тебя удивляет? Скрам - это ярко выраженный процесс ;)

[Тимур]

Так... что там у нас осталось из крупных проблем?

Вот это

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

 

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

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

 

Скажем говорим, что нельзя менеджеру ставить новую задачу, если у него уже в очереди больше 10 :-) Скажем, черновики тасков идут в беклог проекта. Когда начинается новый спринт мы берем в него только 10 тасков. А дальше менеджеры должны договориться что у нас приоритетней и почему. (получился скорее скрам, ну черт с ним). Ну и почему у нас все так медленно и "чем можно помочь".

 

 

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

 

 

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

 

 

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

 

 

 

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

 

 

Ну... примерно все.

Если что-то вспомню - еще отпишу.

 

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

 

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