[Тимур]

Интересен другой вопрос, если Ринет уже несколько раз трансформировался,

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

чем трансформироваться ?

 

Особых трансформаций не было. Было отращивание новых направлений, когда удавалось нащупать перспективный сегмент.

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

 

А сколько трасформаций хотя бы видов деятельности у Ринета за эти 20 лет было ?

 

2.5-3 (как считать) :-)

[Тимур]

А если к теме, то конкретно меня интересует вполне определенный вопрос.

 

Что кроме бубна и топора может мне предложить многоуважаемый Олл?

Мы довольно много времени практиковали использование трекера.

Наверное, толк от него был некоторый. Но без канделябра не работает.

 

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

 

 

Я пожалуй еще порассказываю на эту тему немного.

 

Ситуация эволюционировала следующим образом.

 

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

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

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

 

 

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

- у задачи большой жизненный цикл

- у задачи есть ветвления

 

Почему так?

 

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

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

 

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

 

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

 

Но как?

 

Я вот например не знаю интерфейсной идеи, которая бы визуализировала состояние дел по пулу проектов, где перемешаны проекты ординарные и проблемные

(Верю - что такая идея должна быть - надеюсь на вас, дорогие форумчане!)

 

 

Вторая проблема это ветвления.

 

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

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

 

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

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

То есть точечно ситуация разруливается.

 

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

 

Ответьте на этот вопрос и вы на полпути к тому, чтобы сделать над тикетной системой проектную надстройку.

 

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

 

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

 

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

 

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

[SergeiK]

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

И мне кажется, что это совершенно не верно!

Конечно, руководитель, работающий в процессе лучше всех его знает!

Но, во-первых, работать в процессе и менять его - вещи совершенно разные.

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

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

Ну и, по моему опыту, тому, кто работает в процессе, нельзя работать в проекте, одновременно! И наоборот, конечно.

 

То есть, я полностью согласен с Kirya, что это должен быть отдельный человек, который и должен вести все эти проекты.

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

Да, и этим человеком не может быть главный Директор, у него другие задачи.

[Negator]

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

[SergoINFOLAN]

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

вопрос - краткий доклад и состояние задачи,

сразу же принимается УСТНОЕ решение и т.д.

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

Для ветвлений подходит, и для долгих этапов. Блокнот и ручка, всё!

[Тимур]

Ну... сделаю оговорочку.

Слово проект очень многозначное. Каждый в это слово вкладывает какой-то свой набор смыслов.

 

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

 

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

 

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

 

Реальный же проект во взрослом смысле этого слова начинается тогда когда

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

- есть конкретные сроки с санкциями

- твои яйца отданы в залог какому-нибудь Лаврентию Зиямагомедовичу Аксельроду

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

 

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

(альфа - потому что такими штуками занимаются альфа-самцы)

 

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

 

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

[SergoINFOLAN]

Но, во-первых, работать в процессе и менять его - вещи совершенно разные.

+1

именно для этого были комиссары в помощь директорам заводов при СССР.

[SergoINFOLAN]

проект (маленькими буквами)

Ежедневник и ручка. В нём записи что надо сделать и кому. Условные символы - троеточие=делается (каждая точка этап). галочка = пройден этап. Зачёркнуто = сделано. Подробности в голове и приложенных документах (как на бумаге так и в эл.виде).

Всё.

[Тимур]

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

И мне кажется, что это совершенно не верно!

Конечно, руководитель, работающий в процессе лучше всех его знает!

Но, во-первых, работать в процессе и менять его - вещи совершенно разные.

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

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

Ну и, по моему опыту, тому, кто работает в процессе, нельзя работать в проекте, одновременно! И наоборот, конечно.

 

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

 

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

 

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

[SergeiK]

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

Я говорю в точности про такие же "проекты".

 

Мне довелось поработать в большой компании, как часть ОЧЕНЬ большой компании, с древними процессными и проектными традициями.

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

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

 

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

 

То есть, для использования проектных подходов не обязательны МЕГА задачи, их можно применять и микрозадачах, желательно соизмеряя затраты и результаты, конечно :).

[Тимур]

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

 

У нас в конторе есть конкретный закидон. 90% костяка компании адово дорожат персональной свободой и крайне неприязненно относятся к идее администрирования сверху. Это у нас необсуждаемый фетиш и стержень корпоративной культуры. Еще и раздолбайство является скорее доблестью нежели пороком.

 

Вопрос - как нашей маленькой анархической республике выживать во враждебном капиталистическом окружении?

 

Ответ, который нащупал я. Он состоит из двух пунктов.

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

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

 

В настройке бизнес-процессов это в целом прокатывает. Может и в проектах прокатит.

Хотя ничего нельзя сказать наверняка. Можем и прогореть - кто знает?

[SergeiK]

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

И мне кажется, что это совершенно не верно!

Конечно, руководитель, работающий в процессе лучше всех его знает!

Но, во-первых, работать в процессе и менять его - вещи совершенно разные.

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

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

Ну и, по моему опыту, тому, кто работает в процессе, нельзя работать в проекте, одновременно! И наоборот, конечно.

 

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

 

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

 

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

Обязательно взаимодействовать, а как же иначе!

 

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

 

Я не уверен, что товарищ Прохожий меня поддержит, но для меня в проекте ключевых моментов несколько:

1. Постановка задачи, тот самый мифический SMART. То есть руководитель проекта должен понять хотелки всех участников проекта, описать их предметно и чтоб потом можно было оценить результаты, хотя бы по схеме: получилось/не получилось.

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

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

[Тимур]

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

вопрос - краткий доклад и состояние задачи,

сразу же принимается УСТНОЕ решение и т.д.

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

Для ветвлений подходит, и для долгих этапов. Блокнот и ручка, всё!

 

Мысль ясна. Такой подход вполне себе работоспособен.

У нас не приживется.

 

Мы не приемлем власть людей.

Поэтому хотим уйти под власть роботов :-)))

[Kirya]

Поэтому хотим уйти под власть роботов :-)))

Тим, любой Project Management всё-равно администрируется людьми.

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

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

 

Ну поставишь ты какую-нибудь систему.

Как быстро твои коллеги рюхнут, что администрирует и контролирует её некто Тимур,

а все напоминалки - это просто аналоги канделябра ?

[Sergey Gilfanov]

Реальные проблемы начинаются когда

- у задачи большой жизненный цикл

- у задачи есть ветвления

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

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

[Kirya]

Тим, и почитай про Scrum.

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

Там есть очень прикольная фишка - диаграмма сгорания задач.

Может это наглядно покажет твоим коллегам в чём состоит ценность работы над проектом ?

[SergoINFOLAN]

У нас не приживется.

 

Мы не приемлем власть людей.

Поэтому хотим уйти под власть роботов

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

[Тимур]

1. Постановка задачи, тот самый мифический SMART. То есть руководитель проекта должен понять хотелки всех участников проекта, описать их предметно и чтоб потом можно было оценить результаты, хотя бы по схеме: получилось/не получилось.

 

О!

"И сюда они добрались" (с) анекдот про инопланетян в кибуце

 

 

О смарте и импакте... а также о том какие еще бывают проекты кроме альфапроектов.

 

Но сначала вернемся чуть-чуть назад - к моему повествованию о треккерах.

 

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

 

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

- быстрый жизненный цикл

- отсутствуют ветвления

- ясные параметры нахождения в этапах (единство ответственного, единство состояния)

- хорошая типизация и не очень сильно плавают параметры

- все очевидно с целями (починить, доставить, проложить)

 

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

 

- кабеля по колодцам (длинные)

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

- разработка софта (без комментариев)

- учет управленческих задач (тема нашей беседы)

 

 

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

И стал смотреть мир в поисках альтернативы.

 

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

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

 

 

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

 

Еще раз отпрыгнем назад.

 

Откуда взялся раздел с управленческими задачами/проектами?

 

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

 

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

 

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

 

Четвертая причина - управленческие задачи далеко не на 100% сводятся к моим распоряжениям менеджерам - есть еще огромный пласт запросов менеджеров друг к другу. Соответственно всем удобнее когда конкретно понятно - кто чего и от кого хочет. И четко понятно кто кого и в каких вопросах стопит.

 

Ну как-то так. Уже достаточно.

 

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

 

Однако!

 

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

 

И в процессную модель они действительно укладываются плохо.

 

И самая важная здесь причина - это... наличие подзадач и подзадач.

 

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

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

 

Ну то есть даже, если мы бьем болт на учет ресурсов, управление сроками, формализацию критериев цели и другой ПРОЕКТНЫЙ фарш (потому что МОЖЕМ :-) ) - у нас все равно остается серьезнейшая неопределенность с вложениями.

 

А потому планарная модель учета тасков нам уже ну никак не подходит.

 

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

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

 

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

[Sergey Gilfanov]

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

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

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

 

В данном случае получается

Требование: "Хотим порядок в базе администраций"

Дальше оно дробится:

"Это требование будет считаться выполненным, когда <и список на десяток пунктов>" (А вот тут придется подумать над тем, чего именно хочется)

Далее по рекурсии.

 

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

 

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

[SergeiK]

1. Постановка задачи, тот самый мифический SMART. То есть руководитель проекта должен понять хотелки всех участников проекта, описать их предметно и чтоб потом можно было оценить результаты, хотя бы по схеме: получилось/не получилось.

Однако!

 

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

С этого места не согласен.

Управленческие задачи разные.

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

 

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

В том числе, проработкой отдельных необходимых задач.

 

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

Все их зависимости - хоть в MS Project, хоть в других системах, которые стоят диаграмму Ганта. Управление ресурсами для тебя, как я понимаю, в этих проектиках не очень востребовано, все вручную.

Что еще надо-то?

[Тимур]

Мда... отвлекся.

 

Ну так я же обещал еще потрепаться за СМАРТ с импактом и другой скрам...

 

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

 

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

 

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

 

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

 

 

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

 

Но ключевые мысли в плане управления проектами следующие

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

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

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

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

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

 

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

 

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

[Тимур]

Ну и вот.

 

А теперь очередное отступление в сторону.

 

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

 

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

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

 

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

[Тимур]

Кстати, ничего что я так много матерюсь?

Просто я пьян и очень устал... если кого-то напрягает - жалуйтесь - я потом пройдусь и подредактирую...

 

м.... ну так вот.

 

А теперь о грустном.

 

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

Но короче, заниматься прояснением целей на практике ДИКО ТЯЖЕЛО. Это ну просто нужно вывернуть голову на изнанку. Полностью идет в разрез с предыдущими практиками.

 

Очень тяжело корректно формулировать цели. Вот спрашивается зачем нам нужен новый биллинг? Не так - ЗАЧЕМ нам нужен новый биллинг? Нужен и все тут.

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

 

Львиную долю проектов представляют всякая фигня, где глупо даже и задаваться таким вопросом. Зачем нужно связать контур модернизации с группой обслуживающих крупных корпов? Да вроде и так понятно зачем. Чего мы хотим добиться? Ну чтобы аварийность по крупнякам снизилась и модернизационный бюджет расходовался бы оптимальнее. Я реально не понимаю, что я там могу насобирать бродя в дебрях смыслов. Мне например, все предельно очевидно и очень понятно.

 

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

 

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

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

 

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

 

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

 

Для смарта же нужно голову наизнанку вывернуть.

 

Это я молчу еще, например, что у нас массово никто не может планировать. Почему? Ну например потому что 99% людей физиологически не могут планировать в условиях неопределенности. Как только пытаешься докопаться до дженерал менеджера с вопросом "когда ты это закончишь" - у него сто пудово начинается реальная истерика. Он не может ответить на этот вопрос - потому что как правило не владеет половиной ключевых данных и это в лучшем случае.

 

А между прочим, есть еще авралы.

 

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

 

ОК. Мне уже почти сорок лет, я многое про себя знаю. Например я знаю, что я не особенно умный человек. У меня много достоинств, например у меня большое сердце и богатое воображение. Но мозги? Мозгов не хватает. И что мне теперь делать? Самовыпилиться? Не могу - у меня дети и кредиты :-)))

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

 

Ну нет. Мы будем бороться :-)))

 

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

 

Как-то так.

[SergeiK]

Кстати, ничего что я так много матерюсь?

Просто я пьян и очень устал... если кого-то напрягает - жалуйтесь - я потом пройдусь и подредактирую...

 

м.... ну так вот.

Крик души, просто крик души!!! Мы ценим :)!

Может, подискутировать за кружечкой пива :)?

 

 

...

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

 

ОК. Мне уже почти сорок лет, я многое про себя знаю. Например я знаю, что я не особенно умный человек. У меня много достоинств, например у меня большое сердце и богатое воображение. Но мозги? Мозгов не хватает. И что мне теперь делать? Самовыпилиться? Не могу - у меня дети и кредиты :-)))

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

 

Ну нет. Мы будем бороться :-)))

"Нельзя объять необъятное" (с) Козьма Прутков.

 

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

 

 

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

 

Как-то так.

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

[SergoINFOLAN]

все проблемы в головах менеджеров, а не в системе.

золотая цитата