Тимур Опубликовано 28 апреля, 2015 · Жалоба Интересен другой вопрос, если Ринет уже несколько раз трансформировался, и наверное болезненно, почему люди не понимают, что оптимизироваться всегда легче, чем трансформироваться ? Особых трансформаций не было. Было отращивание новых направлений, когда удавалось нащупать перспективный сегмент. Кроме того трансформироваться на растущем рынке всегда значительно веселее, чем оптимизироваться на стагнирующем (а с учетом инфляции и сужающемся). А сколько трасформаций хотя бы видов деятельности у Ринета за эти 20 лет было ? 2.5-3 (как считать) :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Тимур Опубликовано 28 апреля, 2015 · Жалоба А если к теме, то конкретно меня интересует вполне определенный вопрос. Что кроме бубна и топора может мне предложить многоуважаемый Олл? Мы довольно много времени практиковали использование трекера. Наверное, толк от него был некоторый. Но без канделябра не работает. Ну... у нас такая же фигня. Только мы используем свой самописный треккер. Канделябры свои. Я пожалуй еще порассказываю на эту тему немного. Ситуация эволюционировала следующим образом. Изначально у нас не было ничего. Потом для учета аварий поставили gnats. Потом стало понятно, что треккер штука абстрактная и ее можно использовать для разных тикетов - знай поля добавляй. Я попросил админов добавить полей и этапов. На что админы мне отказали, сказав что у них много работы. Я тогда по неграмотности и поскольку меня никто не контролировал совершил очень крупную ошибку - вместо того чтобы дожать админов, нанял программиста, чтобы он написал наш треккер. Сказать по правде, я тогда был очарован той легкостью, с которой наш программист делал CRM - и подумал, что программирование это очень просто.... ну сделанного не воротишь. Короче мы начали писать свой треккер и так его до сих пор и докручиваем (10 лет уже скоро будет) Ну так вот. Треккеры прекрасно описывают линейно развивающиеся бизнесы-процессы с коротким жизненным циклом. А таких надобно сказать подавляющее большинство. Если туда докрутить всяких кнопок, скриптов, API и прочего кода - то и вовсе можно жить. Сказать по правде я не видел других треккеров (кстати кто гоняет OTRS - поделитесь опытом) - но мне кажется, что они все в душе одинаковые. Реальные проблемы начинаются когда - у задачи большой жизненный цикл - у задачи есть ветвления Почему так? За треккером очень просто следить по самому факту наличия задачи в определенном этапе и времени нахождения в этапе. Возьмем к примеру аварийный процесс. Смотрим на главную страницу смотрим на цифру "количество аварий в состояниях "новое", и "в работе" ну и в общем-то все понятно. Две цифры полностью отвечают на вопрос как идут дела. Туда можно поглядывать и идти к аварийщикам интересоваться их проблемами если, цифры в этих этапах неприятно велики. Поскольку мы знаем приемлемый уровень нахождения заявки в этапе, можно тривиально включить скрипт эскалации. Если же у задачи большой жизнененный цикл, то в терминах треккера это означает, что она может неопределенно долго болтаться во вработе. В нашем случае такой задачей является к примеру задачи "подземки". Пока МГТС и коллектора со своими допусками разговняться, пока преодолеются непроходы, пока менеджеры, администрации и инженера все между собой пересогласуют порой можно и ребенка родить. Отсюда простое последствие - понять как идут дела можно только одним способом - еженедельно проводить совещания и каждый раз интересоваться судьбой каждого таска. А это не подходит для вас, если только вы не хотите заниматься именно этим до самой смерти. Вышеуказанный пример возвращает нас к одному из вопросов топика - за проектами нужно следить не так как за процессами. Но как? Я вот например не знаю интерфейсной идеи, которая бы визуализировала состояние дел по пулу проектов, где перемешаны проекты ординарные и проблемные (Верю - что такая идея должна быть - надеюсь на вас, дорогие форумчане!) Вторая проблема это ветвления. Допустим у нас не просто авария, а авария с фишечками. Скажем, мало восстановить связь, нужно еще и провести модернизацию, начислить компенсацию, инициировать софтовый аудит у клиента, проключить его на другой канал и т.д. Совершенно не сложно в концепции линейного треккера (не ветвящегося) - сделать кнопочку, для того чтобы инициировать другой процесс. Вопрос исключительно в интерфейсной идее, которая бы показывала, что таск нельзя закрывать, пока мы не будут решены другие таски в других процессах. Ну то есть... ну то есть мы конечно можем в заголовке таска указать, что к нему есть порожденные им таски (сабтасками это кстати называть не правильно), и отображать их статус. То есть точечно ситуация разруливается. Вопрос в том с помощью какой интерфейсной идеи можно было бы не напрягаясь мониторить состояние пула таких тасков в динамике. Ответьте на этот вопрос и вы на полпути к тому, чтобы сделать над тикетной системой проектную надстройку. И возвращаясь к нашей с Прохожим дискуссии, с опорой на вышеприведенные примеры я бы высказался так Между проектом и процессом нет фундаментальной разницы и то и другое метод агрегации тасков. Вопрос исключительно в сервисах, которые предоставляет система для изучения ситуации. Для контроля процессов нужны одни сервисы, для контроля проектов нужны несколько иные сервисы. А сложность ситуации с проектами заключается в том, что я например не очень понимаю - какие именно сервисы для контроля протекания проектов нужны. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 28 апреля, 2015 · Жалоба Может быть я скажу глупость, но, как я понял так, что улучшать процессы и вести эти мини-проекты должны те же самые руководители, что по этим же процессам и работают. И мне кажется, что это совершенно не верно! Конечно, руководитель, работающий в процессе лучше всех его знает! Но, во-первых, работать в процессе и менять его - вещи совершенно разные. Во-вторых, такому человеку очень сложно выйти за привычные рамки. В-третьих, каждый руководитель будет оптимизировать процессы для себя, а не для компании, и не факт, что оптимальный процесс для отдела будет оптимальный для компании. Ну и, по моему опыту, тому, кто работает в процессе, нельзя работать в проекте, одновременно! И наоборот, конечно. То есть, я полностью согласен с Kirya, что это должен быть отдельный человек, который и должен вести все эти проекты. Этот специальный человек должен предлагать или выбирать свой инструмент для работы. Да, и этим человеком не может быть главный Директор, у него другие задачи. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 28 апреля, 2015 · Жалоба Тимур, а ты вообще уверен что описаные задачи нужно непременно решать каким то трекером или т. п. системой? Автоматизация всего и вся это конечно круто, особенно если есть свободные разработчики, но цель то другая- решать определенные задачи. А решать их будут люди. Правильным решением будет замотивировать людей на решение задач. А разработка трекера говорит о том, что ты хочешь оптимизировать все и управлять всем вручную. Увы, контролировать все не всегда получается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergoINFOLAN Опубликовано 28 апреля, 2015 · Жалоба да зачем все эти рюшечки? Ежедневно проводится собрание у генерального директора, где в блокноте ручкой фиксируется вопрос - краткий доклад и состояние задачи, сразу же принимается УСТНОЕ решение и т.д. Смотрится прогресс проектов(по отношению к прошлым записям в ежедневнике) и т.д. Подходит для командной работы над проектами, где каждый этап - не тривиальный. Для ветвлений подходит, и для долгих этапов. Блокнот и ручка, всё! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Тимур Опубликовано 28 апреля, 2015 · Жалоба Ну... сделаю оговорочку. Слово проект очень многозначное. Каждый в это слово вкладывает какой-то свой набор смыслов. Скажем, когда Прохожий употребляет слово проект ему видится какая-то довольно эпичная картина. Приходит к Прохожему например, кто-то и говорит - надо поставить в абхазии завод по производству мандаринового сока. Сроки такие-то, бабла столько-то. Берешься? Прохожий крепко думает вспонимает все что он знает про абхазию и мандарины(вот откуда упор на уникальность) и допустим говорит берусь. Дальше у него жизнь становится резко интереснее. Я не люблю интересной жизни. Я люблю скуку. Я предпочитаю не ввязываться в истории про которые мне ничего не известно, кроме ограничений по срокам и по бюджету. Я люблю когда наоборот - дело хорошо всем нашим понятно, сроки можно и понянуть, а бюджет... ну что бюджет - когда-нибудь же отобъется :-) В этом смысле надо признать, что многие провайдеры (в том числе и я), у которых бабло на счетах респоунится здорово развращены такой халявой. Реальный же проект во взрослом смысле этого слова начинается тогда когда - есть жесткие ограничения по бюджету (вышел из сметы - прибыль села или ушла в минуса) - есть конкретные сроки с санкциями - твои яйца отданы в залог какому-нибудь Лаврентию Зиямагомедовичу Аксельроду - если по хардкору то еще и есть место неопределенности (это не твое стопервое внедрение Оракла, а первая попытка построить мандариновыжимательный завод, особенно в Абхазии до этого ты занимался только молочными фермами в Поволжье) При наличии вот этих четырех компонентов на самом деле и можно говорить о проекте с большой буквы. Предлагаю, чтобы не путаться в дальнейшем называть такие ситуации АЛЬФАПРОЕКТ (альфа - потому что такими штуками занимаются альфа-самцы) Тогда да. Тогда тебе нужно по взрослому менеджерить ресурсами. Тогда тебе нужно хорошенько представлять себе сроки. Тогда тебе было бы очень желательно надежно определиться с целью проекта (а что собственно заказчик понимает под мандариновыжимательным заводом?) И давайте оговоримся, что я такие ситуации не обсуждаю. Поэтому я дальше буду говорить проект (маленькими буквами) - хорошо понимая, что это всего лишь бледная тень того атомного ***еца, который порой приходится разруливать мощным старикам типа Прохожего. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergoINFOLAN Опубликовано 28 апреля, 2015 · Жалоба Но, во-первых, работать в процессе и менять его - вещи совершенно разные. +1именно для этого были комиссары в помощь директорам заводов при СССР. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergoINFOLAN Опубликовано 28 апреля, 2015 · Жалоба проект (маленькими буквами) Ежедневник и ручка. В нём записи что надо сделать и кому. Условные символы - троеточие=делается (каждая точка этап). галочка = пройден этап. Зачёркнуто = сделано. Подробности в голове и приложенных документах (как на бумаге так и в эл.виде).Всё. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Тимур Опубликовано 28 апреля, 2015 · Жалоба Может быть я скажу глупость, но, как я понял так, что улучшать процессы и вести эти мини-проекты должны те же самые руководители, что по этим же процессам и работают. И мне кажется, что это совершенно не верно! Конечно, руководитель, работающий в процессе лучше всех его знает! Но, во-первых, работать в процессе и менять его - вещи совершенно разные. Во-вторых, такому человеку очень сложно выйти за привычные рамки. В-третьих, каждый руководитель будет оптимизировать процессы для себя, а не для компании, и не факт, что оптимальный процесс для отдела будет оптимальный для компании. Ну и, по моему опыту, тому, кто работает в процессе, нельзя работать в проекте, одновременно! И наоборот, конечно. В данный момент, я пожалуй, с тобой соглашусь. Года два назад (когда я писал нюансы стагнации) я понимал, что стою перед вилкой - или развивать операцинных руководителей или монтировать проектную надстройку. Сейчас я пожалуй понимаю, что без проектной надстройки не обойтись, а от операционного менеджера лучше бы со всякой ерундой ***аться. Это знание стоило мне пары лет и примерно половины штата операционных руководителей :-))) Но с другой стороны проектная надстройка все равно должна теснейшим, я бы даже сказал интимнейшим образом взаимодействовать с операционным костяком. Иначе это будет не сцилла, а харибда. И да - им нужно тоже как-то взаимодействовать, этим пароходом управлять. Поэтому вопрос по информационной системе все равно открыт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 28 апреля, 2015 · Жалоба И давайте оговоримся, что я такие ситуации не обсуждаю. Поэтому я дальше буду говорить проект (маленькими буквами) - хорошо понимая, что это всего лишь бледная тень того атомного ***еца, который порой приходится разруливать мощным старикам типа Прохожего. Я говорю в точности про такие же "проекты". Мне довелось поработать в большой компании, как часть ОЧЕНЬ большой компании, с древними процессными и проектными традициями. Там были большие проекты, в проектном департаменте, от меня далеко и не видно, и проектный отдел в эксплуатации IT, которые решал все вопросы IT, выходящий за рамки разрешения инцидентов и запросов в запросной системе. Установка нового роутера (это был не провайдер, и установка роутера не была совсем уже рутиной, хотя ничего выдающегося, конечно), установка дополнительного коммутатора доступа, организация дополнительного канала связи - это все были проекты, которые вели отдельные руководители проектов. Я не утверждаю, что схема были идеальна, а тогда она мне показались совершенно дикой! Потом я понял, здравое зерно в этом есть, и я его оценил, попав в другую большую компанию. То есть, для использования проектных подходов не обязательны МЕГА задачи, их можно применять и микрозадачах, желательно соизмеряя затраты и результаты, конечно :). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Тимур Опубликовано 28 апреля, 2015 · Жалоба Тимур, а ты вообще уверен что описаные задачи нужно непременно решать каким то трекером или т. п. системой? Автоматизация всего и вся это конечно круто, особенно если есть свободные разработчики, но цель то другая- решать определенные задачи. А решать их будут люди. Правильным решением будет замотивировать людей на решение задач. А разработка трекера говорит о том, что ты хочешь оптимизировать все и управлять всем вручную. Увы, контролировать все не всегда получается. У нас в конторе есть конкретный закидон. 90% костяка компании адово дорожат персональной свободой и крайне неприязненно относятся к идее администрирования сверху. Это у нас необсуждаемый фетиш и стержень корпоративной культуры. Еще и раздолбайство является скорее доблестью нежели пороком. Вопрос - как нашей маленькой анархической республике выживать во враждебном капиталистическом окружении? Ответ, который нащупал я. Он состоит из двух пунктов. - глубокая автоматизация (администрирование берут на себя скрипты и интерфейсы) - мощное премирование по результату (толстый пряник, раз уж у нас нет кнута)(а для этого нужно атомизировать, метрить, учитывать) В настройке бизнес-процессов это в целом прокатывает. Может и в проектах прокатит. Хотя ничего нельзя сказать наверняка. Можем и прогореть - кто знает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 28 апреля, 2015 · Жалоба Может быть я скажу глупость, но, как я понял так, что улучшать процессы и вести эти мини-проекты должны те же самые руководители, что по этим же процессам и работают. И мне кажется, что это совершенно не верно! Конечно, руководитель, работающий в процессе лучше всех его знает! Но, во-первых, работать в процессе и менять его - вещи совершенно разные. Во-вторых, такому человеку очень сложно выйти за привычные рамки. В-третьих, каждый руководитель будет оптимизировать процессы для себя, а не для компании, и не факт, что оптимальный процесс для отдела будет оптимальный для компании. Ну и, по моему опыту, тому, кто работает в процессе, нельзя работать в проекте, одновременно! И наоборот, конечно. В данный момент, я пожалуй, с тобой соглашусь. Года два назад (когда я писал нюансы стагнации) я понимал, что стою перед вилкой - или развивать операцинных руководителей или монтировать проектную надстройку. Сейчас я пожалуй понимаю, что без проектной надстройки не обойтись, а от операционного менеджера лучше бы со всякой ерундой ***аться. Это знание стоило мне пары лет и примерно половины штата операционных руководителей :-))) Но с другой стороны проектная надстройка все равно должна теснейшим, я бы даже сказал интимнейшим образом взаимодействовать с операционным костяком. Иначе это будет не сцилла, а харибда. И да - им нужно тоже как-то взаимодействовать, этим пароходом управлять. Поэтому вопрос по информационной системе все равно открыт. Обязательно взаимодействовать, а как же иначе! Просто вопрос по всем нелинейным взаимосвязями задач проекта в логику системы засунуть не просто, это и есть одна из ключевых задач руководителя проекта. Я не уверен, что товарищ Прохожий меня поддержит, но для меня в проекте ключевых моментов несколько: 1. Постановка задачи, тот самый мифический SMART. То есть руководитель проекта должен понять хотелки всех участников проекта, описать их предметно и чтоб потом можно было оценить результаты, хотя бы по схеме: получилось/не получилось. 2. Оценка рисков. Крайне сложный вопрос, если по взрослому, но до этого, к счастью, доходит редко. К сожалению, часто вообще не доходит. 3. Внятная регулярная отчетность, чтоб и руководитель проекта и заказчик понимали как можно раньше, что возник затык, и требуется разбирательство, волшебный пендель, привлечение дополнительных ресурсов или еще чего! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Тимур Опубликовано 28 апреля, 2015 · Жалоба да зачем все эти рюшечки? Ежедневно проводится собрание у генерального директора, где в блокноте ручкой фиксируется вопрос - краткий доклад и состояние задачи, сразу же принимается УСТНОЕ решение и т.д. Смотрится прогресс проектов(по отношению к прошлым записям в ежедневнике) и т.д. Подходит для командной работы над проектами, где каждый этап - не тривиальный. Для ветвлений подходит, и для долгих этапов. Блокнот и ручка, всё! Мысль ясна. Такой подход вполне себе работоспособен. У нас не приживется. Мы не приемлем власть людей. Поэтому хотим уйти под власть роботов :-))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kirya Опубликовано 28 апреля, 2015 · Жалоба Поэтому хотим уйти под власть роботов :-))) Тим, любой Project Management всё-равно администрируется людьми. Ибо фактически все системы управления проектами фактически есть по сути электронная бумажка для записи и встроенный мессенжер. Дальше вкусовщина и заточенность под фичи разных методик управления под конкретные отрасли. Ну поставишь ты какую-нибудь систему. Как быстро твои коллеги рюхнут, что администрирует и контролирует её некто Тимур, а все напоминалки - это просто аналоги канделябра ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Gilfanov Опубликовано 28 апреля, 2015 · Жалоба Реальные проблемы начинаются когда - у задачи большой жизненный цикл - у задачи есть ветвления По поводу ветвлений и долговременных задач. Вроде бы ближайший "софтовый" термин - управление требованиями. Там и зависимости (для того, чтобы считать, что это требование выполненным надо....) и долговременность (ну просто вот висит оно так задокументированное "было создано тогда-то, занимается тот-то"). Если нужна историческая перспектива - уталкиваем весь этот документ в систему контроля версий. Автоматизации, разумеется, никакой не будет. Но такие длинные задачи ведь и не потоком идут? Можно руками все завести. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kirya Опубликовано 28 апреля, 2015 · Жалоба Тим, и почитай про Scrum. https://ru.wikipedia.org/wiki/Scrum Там есть очень прикольная фишка - диаграмма сгорания задач. Может это наглядно покажет твоим коллегам в чём состоит ценность работы над проектом ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergoINFOLAN Опубликовано 28 апреля, 2015 · Жалоба У нас не приживется. Мы не приемлем власть людей. Поэтому хотим уйти под власть роботов для Тимура будет идеальным несколько ООО и не зависимых ГД - реальная власть не роботов, а рынка. ГД имеет право сделать что угодно, полная свобода, нет власти центрального ООО. и делайте разные проекты как хотите! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Тимур Опубликовано 28 апреля, 2015 · Жалоба 1. Постановка задачи, тот самый мифический SMART. То есть руководитель проекта должен понять хотелки всех участников проекта, описать их предметно и чтоб потом можно было оценить результаты, хотя бы по схеме: получилось/не получилось. О! "И сюда они добрались" (с) анекдот про инопланетян в кибуце О смарте и импакте... а также о том какие еще бывают проекты кроме альфапроектов. Но сначала вернемся чуть-чуть назад - к моему повествованию о треккерах. Итак постепенно мы загнали в нашу тикет систему все стандартные бизнес-процессы. От аварий до разбитой лампочки и от разборок по невыставленным счетам до штрафования чуваков, которые косячат. Навесили всяких сервисов, интеграций и т.д. А мы из предыдущего куска помним, что на треккерных системах успешно автоматизируются бизнес-процессы у которых - быстрый жизненный цикл - отсутствуют ветвления - ясные параметры нахождения в этапах (единство ответственного, единство состояния) - хорошая типизация и не очень сильно плавают параметры - все очевидно с целями (починить, доставить, проложить) Ну так вот. Несмотря на то, что такой подход оказался в целом успешным, появились-таки задачи, которые плохо укладывались в треккерную модель - кабеля по колодцам (длинные) - подключение районов (если относится к дому как к таску, то дофига тасков, если относиться к району как к проектов, то из-за недостроя не получается закрывать проекты) - разработка софта (без комментариев) - учет управленческих задач (тема нашей беседы) Ну так вот. В какой-то момент я с болью и горечью осознал, что с привычного треккера таки надо слезать. Потому что модель описывает не все. И стал смотреть мир в поисках альтернативы. Ну... что я там посмотрел и какое от всего этого у меня осталось впечатление это отдельный вопрос. Но скажу, что наиболее перспективной мне показалась джира. С тем что делать с процессами в джире все было совершенно понятно. Открытым оставался только вопрос - а стоит ли ради нескольких уродских бизнес-процессов перетаскивать все. Тем более что лицензии довольно дорогие... а пользователей нужно переучивать... а все интеграционные скрипты переписывать... стоит ли? А если не перетаскивать остальное то как будут жить уродские бизнес-процессы в изолированной среде? И это же опять зоопарк... не проще ли терпеть уродскость уродских бизнес-процессов, тем более что мы научились форсить проблемы модели чисто организационными методами? Интрига была в управленческих задачах. Если есть смысл валить из треккера на джиру с управленческими проектами, то можно тогда уже и все остальное по тихоньку перевести. Если не имеет смысл, то можно жить как жили. Еще раз отпрыгнем назад. Откуда взялся раздел с управленческими задачами/проектами? Причина тривиальна. В какой-то момент накопился груз ситуаций, когда менеджеры забывали мои приказы, или путались в них, указывая мне что "ты этого не говорил". А учитывая, что я половину времени провожу в не слишком-то вменяемом состоянии и сам знаю, что порой бываю нечеток в формулировках - вопрос встал прежде всего передо мной - я должен был научиться перестать отдавать устные и почтовые распоряжения и перейти на систему, что приказом является только то, что записано в треккере - остальное пустой треп, на который запрещено обращать внимание. Вторая важная причина перейти к учету управленческих задач в треккере - это определение приоритетов. Если задач слишком много - можно сесть и разобраться (так это отменяем, это ну его в жопу, это давай сделаешь не ты, это нужно делать прямо сейчас, это давай сделаем потом) Третья причина - по ритму закрытия можно во внятной форме увидеть с какой скоростью руководитель подразделения/специалист закрывает управленческие задачи. Ремарка - управленческие задачи конечно кофликтуют за ресурс времени/внимания с текучкой. Но если человек несколько периодов подряд не _сделал_ ничего, то это естественным образом подводит нас к вопросу о расставании. Четвертая причина - управленческие задачи далеко не на 100% сводятся к моим распоряжениям менеджерам - есть еще огромный пласт запросов менеджеров друг к другу. Соответственно всем удобнее когда конкретно понятно - кто чего и от кого хочет. И четко понятно кто кого и в каких вопросах стопит. Ну как-то так. Уже достаточно. Поэтому в какой-то момент большинство управленческих задач стало жить в треккере. Однако! Тут-то мы в плотную подошли к теме топика. Потому что большая часть управленческих задач это все-таки проекты. Ну пусть проектики. И в процессную модель они действительно укладываются плохо. И самая важная здесь причина - это... наличие подзадач и подзадач. Смысл тут вот какой. То что для меня это одна строчка "наведите порядок в базе администраций", плюс описание (косяк а, б, с, д нужно е, к, л, м) для человека, который будет этим реально заниматься - может год напряженной работы. Причем он должен задействовать ресурсы других менеджеров - программисты должны что-то там переписать в СРМ, руководители менеджеров должны убедить менеджеров актуализировать контакты, еще какое-то говно нужно учесть в бюджетной системе, отформатировать процедуру передачи объекта в эксплуатацию, все это нужно со всеми согласовать, потому что все держат в своих усталых руках какую-то деталь от слона. Слон кстати, еще и шевелится :-))) И на каждом уровне одна строчка превращается в кучу работы каких-то реальных людей. А есть еще авралы... например государство внезапно решает устроить какой-нибудь декаданс с НДС, и резко всем становится сильно не до чего. Ну то есть даже, если мы бьем болт на учет ресурсов, управление сроками, формализацию критериев цели и другой ПРОЕКТНЫЙ фарш (потому что МОЖЕМ :-) ) - у нас все равно остается серьезнейшая неопределенность с вложениями. А потому планарная модель учета тасков нам уже ну никак не подходит. А надобно сказать, что мне к тому моменту уже адово надоели программистские проекты :-) Поэтому я решил поменять флаг и поставил рабочей группе задачу - разобраться что там есть сейчас из систем. Как изящно выразился давеча в своем блоге Миша Климарев "чятик, подскажи проджект-треккер модный?" И теперь возвращаемся на шаг вперед, когда по результатам исследования я пришел к выводу, что джира перспективней остальных. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Gilfanov Опубликовано 28 апреля, 2015 · Жалоба Смысл тут вот какой. То что для меня это одна строчка "наведите порядок в базе администраций", плюс описание (косяк а, б, с, д нужно е, к, л, м) для человека, который будет этим реально заниматься - может год напряженной работы. Самое сложное работе головой - упрощать, когда все хочет усложнится. Как я уже сказал - больше всего это похоже на управление требованиями. Оно идейно тупое как пробка но жутко много писанины и работы головой. В данном случае получается Требование: "Хотим порядок в базе администраций" Дальше оно дробится: "Это требование будет считаться выполненным, когда <и список на десяток пунктов>" (А вот тут придется подумать над тем, чего именно хочется) Далее по рекурсии. Обращаю внимание, что к задачам оно ортогонально. Где-то в требованиях может быть чего-нибудь вида "когда эту чертову яму ЖКХ закопает", что не таск и тем более не проект, а просто явление в окружающей действительности. Теперь про 'требований слишком много' (а их будет много - методика такая). Соответствующий инструментарий, по идее, строит таки граф зависимостей и подсказывает узловые точки. Отсюда уже и приоритеты вытаскиваются. Ну и на каждую хотелку получается подробная документация для каких именно целей мы это захотели. Если чего-то изменилось - тот же инструментарий помогает выкидывать лишнее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 28 апреля, 2015 · Жалоба 1. Постановка задачи, тот самый мифический SMART. То есть руководитель проекта должен понять хотелки всех участников проекта, описать их предметно и чтоб потом можно было оценить результаты, хотя бы по схеме: получилось/не получилось. Однако! Тут-то мы в плотную подошли к теме топика. Потому что большая часть управленческих задач это все-таки проекты. Ну пусть проектики. С этого места не согласен. Управленческие задачи разные. Если у руководителя операционного подразделения появляются задачи "проекты", он их или не сделает, или сделает на "отстань" или сделает так, как надо ему, а не компании. Поэтому такие проектики должен делать другой человек, который тщательно выяснит, что надо операционному руководителю, что надо в связи с этим компании, кто еще в это будет замешан, а надо ли оно вообще, а что думает про это мировое сообщество, все запишет, по мере возможности формализует, согласует с командиром, операционным руководителем и займется дальнейшими вопросами. В том числе, проработкой отдельных необходимых задач. Все отдельные задачи, которые по этому вопросу возникнут позже, точно так же проходят по стандартным системам. Все их зависимости - хоть в MS Project, хоть в других системах, которые стоят диаграмму Ганта. Управление ресурсами для тебя, как я понимаю, в этих проектиках не очень востребовано, все вручную. Что еще надо-то? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Тимур Опубликовано 28 апреля, 2015 · Жалоба Мда... отвлекся. Ну так я же обещал еще потрепаться за СМАРТ с импактом и другой скрам... Ну и вот. К этому моменту я уже понимал, что не очень-то продуктивно смотреть на демки. В модели все у всех неплохо. Нужно посмотреть как ведет себя система в нагруженной ситуации - ну там... пару лет эксплуатации, куча проектов, куча тасков, реальные люди, которые не очень-то жаждут заполнять формы... Ну и пообщаться с людьми, которые всем этим занимаются на интересующие меня темы. А поскольку известно, что на джире живет яндекс, а в яндексе работает лейден, я конечно спросил его. А он мне в ответ посоветовал парня, который в яндексе джирой рулил. Ну вот... а еще до того как я стал дерагать лейдена, я просто начал с того, что попытался пообщаться с сертифицированным атласианавским внедрнцем по беспокоящим меня вопросам. Ответы внедренца были крайне невнятны и сводились к мысли, что не парьте мозг, а просто начните пользоваться. При этом он рассказывал о прижившихся практиках использования и я не услышал ничего такого, что мы бы уже не имели реализованным на нашем треккере. Вот почему я был так заинтересован в общении с опытными практиками ведения проектов в джире. Меня собственно интересовали совершенно простые вопросы - на тему сервисов, которые предоставляет система для решения стандартных (как мне кажется) юзеркейсов. Опытный человек из яндекса выслушав нашу проблему, объяснил, что мои вопросы по сути лишены смысла. В джире можно сделать все. А начинать нужно с правильной методологии - иначе система развалится. Иными словами, прежде чем лезть конфигруировать джиру нужно сначала иметь правильные представления о том как нужно управлять проектами. Более того он оказался настолько любезен, что согласился дать нам серию консультаций по совершенно смехотворному прайсу. По скольку я тогда твердо нацелился на джиру, я подумал что - нужно брать. Мы и поймем как получше с проектами управляться и как это делать конкретно применительно к джире. Ну... дальше я буду несколько невнятен... во-первых и поздно, и завтра рано вставать... и мы еще к этому вопросу вернемся... и многое я забыл, а многое понял наверное превратно... Но ключевые мысли в плане управления проектами следующие - самое важное перед тем как ты затеял что-то делать - очень хорошо разобраться с вопросом - зачем ты это делаешь. - ответ на вопрос зачем должен быть сформулирован в бизнес-терминах (как заработать бабла или сделать что-то еще влияющее на миссию компании) - ответ на вопрос зачем должен быть сформулирован по смарту, (то есть конкретен, измерим, достижим, полезен, ограничен по времени) иначе это говно, а не цель... и проект будет унитазом, в которой уйдут любые ресурсы.. - отвечать на вопрос "зачем" очень важно, потому что декомпозиция ответа на этот вопрос часто приводит нас к тому, что решить задачу можно по другому, проще или вообще ее не решать - ведя работу по проекту необходимо регулярно сверять таски тактического уровня со стратегическими целями и если у нас что-то идет не так - перепроектировать таски Что же касается собственно джиры, то в итоге я понял, что ничего специального для управления проектами там нет. Есть учет тасков и есть богатые возможности по их тегировке в интересах собственно управления проектами. А уж тегировка это прежде всего вопрос искуства правильной декомпозиции, то есть опять же навык PM. Более того - по признанию этого человека в том же яндексе, никакого специального сервиса по контролю за проектами нет. А все держится на том, что бодрые и смышленые проджектменеджеры бегают и все что им нужно проталкивают. Если значит подохло, то и черт с ним. Или правда не нужно или PМ говно - фигня найдем другого. Иными словами, вывод таков - миграция с нашего треккера на джиру не дает нам практически ничего, потому что все проблемы в головах менеджеров, а не в системе. А то что нужно у нас и так есть в треккере - вопрос исключительно в формировании у менеджмента необходимых в работе с проектами навыков. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Тимур Опубликовано 28 апреля, 2015 · Жалоба Ну и вот. А теперь очередное отступление в сторону. Вооруженные этим священным знанием, мы теперь пожалуй можем кроме альфапроектов выделить еще одну группу. В отличии от альфа проектов, где есть полная определенность с требованиями, есть твердое представление о последовательности их достижения и интрига заключается исключительно в способности проползти сквозь ограничения - есть совсем другая история. Это целый класс ситуаций, когда мы имеем существенную неопределенность в целях или методах достижениях целей. Такой класс проектов давайте называть X-проектами. Проще всего в этот класс укладываются всякие ситуации, когда например команда людей затеивает делать вебдванольный стартап. Мы уже выше касались этого вопроса. И да тут тоже можно и нужно заниматься планированием, и этапированием, всяческой декомпозицией но существенно смещается центр тяжести проблемы. В альфа-проектах центртяжести это учет ресурсов, а сами таски особому сомнению не подвергаются (Зачем забить свайное поле? Чиво-чиво???) В X-проектах вопрос зачем - ключевой. Задача сделать рекламную компанию. А зачем? Ну чтобы привести пользователей. А кто у нас пользователи и чего они хотят.... ну и так далее. В итоге после проработки определенного числа итераций выясняется, что нам не нужна никакая рекламная компания, а в нашем случае нужно наоборот - нев***енно дорого продавать инвайты.... как-то так. И да - если альфа проектами занимаются такие суровые дядьки на джипах, то X-проектами занимаются модные чуваки на самокатах и в худи. А уж просрут ли они деньги или озолотят кого-то зависит в обоих случаях от мозгов и правильных навыков. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Тимур Опубликовано 28 апреля, 2015 · Жалоба Кстати, ничего что я так много матерюсь? Просто я пьян и очень устал... если кого-то напрягает - жалуйтесь - я потом пройдусь и подредактирую... м.... ну так вот. А теперь о грустном. Первые же попытки работать с проектами по методике, грубо говоря провалились. Почему? Хороший вопрос. Наверное честный ответ будет таков - просто не хватает мозгов. У нас там была рабочая группа, лучшие люди... Но короче, заниматься прояснением целей на практике ДИКО ТЯЖЕЛО. Это ну просто нужно вывернуть голову на изнанку. Полностью идет в разрез с предыдущими практиками. Очень тяжело корректно формулировать цели. Вот спрашивается зачем нам нужен новый биллинг? Не так - ЗАЧЕМ нам нужен новый биллинг? Нужен и все тут. Попытка анализировать кончается ничем. Ну что-то там можно делать быстрее... ну мы и в старом это делаем не так уж медленно... ну что-то там можно будет учитывать корректно, а не через жопу... ну и что что мы сейчас учитываем через жопу - это что как-то влияет на прибыль? Ну и так далее. И это замечу по нашим меркам большой проект - где сам бог велел повозиться с целями, требованиями и всем остальным. Так таких проектов мало. Львиную долю проектов представляют всякая фигня, где глупо даже и задаваться таким вопросом. Зачем нужно связать контур модернизации с группой обслуживающих крупных корпов? Да вроде и так понятно зачем. Чего мы хотим добиться? Ну чтобы аварийность по крупнякам снизилась и модернизационный бюджет расходовался бы оптимальнее. Я реально не понимаю, что я там могу насобирать бродя в дебрях смыслов. Мне например, все предельно очевидно и очень понятно. Соответственно я формулирую таски в терминах что нужно сделать, а не в терминах какого результата мы ожидаем. И я нифига не один такой. Примерно в таком же ключе варит котелок примерно у всех в нашей компании. Никто из тех, кто пытался работать по методике ничего путного не выскреб. В принципе я умом-то понимаю, что если найти такого проницательного *** мутанта, который сможет докапываться до сути - мы можем нарезать адовый объем эффективности. Понятно, что 80% энергии менеджеров идет в утиль. И если я такого увижу - я его немедленно попытаюсь нанять. Но какова вероятность, что такое чЮдо свободное и нежадное будет проплывать мимо моих цепких лапок? Не высока, прямо скажем. Но что мы будем делать, если такого не найдем? Воспитывать себя? Для этого нужно чтобы хоть у кого-то хоть что-то получалось. Для сравнения - есть к примеру вполне человеческая методика - GTD. Продуктивно ею воспользоваться может ну прямо таки любой человек. Чтобы ее худо бедно пустить почти ничего не нужно. Для смарта же нужно голову наизнанку вывернуть. Это я молчу еще, например, что у нас массово никто не может планировать. Почему? Ну например потому что 99% людей физиологически не могут планировать в условиях неопределенности. Как только пытаешься докопаться до дженерал менеджера с вопросом "когда ты это закончишь" - у него сто пудово начинается реальная истерика. Он не может ответить на этот вопрос - потому что как правило не владеет половиной ключевых данных и это в лучшем случае. А между прочим, есть еще авралы. Тут с одной стороны вы можете мне сказать. Ну ты Тимур сам виноват. Раз ты не можешь формулировать цели, ну значит и быть тебе вечно в жопе - сиди и не плачь. Ну или старайся умнеть. И людей только умных набирай - вот и весь сказ. А то что умному человеку в общем-то нечего делать в коммунальном предприятии с этим как быть? ОК. Мне уже почти сорок лет, я многое про себя знаю. Например я знаю, что я не особенно умный человек. У меня много достоинств, например у меня большое сердце и богатое воображение. Но мозги? Мозгов не хватает. И что мне теперь делать? Самовыпилиться? Не могу - у меня дети и кредиты :-))) И где взять по взрослому умных менеджеров в таких объемах на такие деньги? Мы что должны сказать себе, что раз мы идиоты, то должны взять лопату выкопать могилку на обочине истории и там тихо сдохнуть? Ну нет. Мы будем бороться :-))) Вот почему нам нужна система управления проектами. Ну такая... чтобы особенно не надо было по взрослому думать. Как-то так. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 29 апреля, 2015 · Жалоба Кстати, ничего что я так много матерюсь? Просто я пьян и очень устал... если кого-то напрягает - жалуйтесь - я потом пройдусь и подредактирую... м.... ну так вот. Крик души, просто крик души!!! Мы ценим :)! Может, подискутировать за кружечкой пива :)? ... Тут с одной стороны вы можете мне сказать. Ну ты Тимур сам виноват. Раз ты не можешь формулировать цели, ну значит и быть тебе вечно в жопе - сиди и не плачь. Ну или старайся умнеть. И людей только умных набирай - вот и весь сказ. А то что умному человеку в общем-то нечего делать в коммунальном предприятии с этим как быть? ОК. Мне уже почти сорок лет, я многое про себя знаю. Например я знаю, что я не особенно умный человек. У меня много достоинств, например у меня большое сердце и богатое воображение. Но мозги? Мозгов не хватает. И что мне теперь делать? Самовыпилиться? Не могу - у меня дети и кредиты :-))) И где взять по взрослому умных менеджеров в таких объемах на такие деньги? Мы что должны сказать себе, что раз мы идиоты, то должны взять лопату выкопать могилку на обочине истории и там тихо сдохнуть? Ну нет. Мы будем бороться :-))) "Нельзя объять необъятное" (с) Козьма Прутков. Нельзя быть сильным во всем. И нет смысла тянуть пытатся вытянуть свои слабые стороны, ибо дотянешь ты их, максимум, до середины и будешь серединой. Надо тянуть сильные стороны, и стать в чем-то лучшим. И найти того, кто прикроет твои слабые стороны. Вот почему нам нужна система управления проектами. Ну такая... чтобы особенно не надо было по взрослому думать. Как-то так. Лично я уверен, попытка программно заткнуть отсутствие навыков проектного управление обречено на провал! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergoINFOLAN Опубликовано 29 апреля, 2015 · Жалоба все проблемы в головах менеджеров, а не в системе. золотая цитата Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...