YouTrack и управление портфелем проектов

Мне кажется, что сообществу YouTrack это будет полезно, но я не нашел где оно живет.

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

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

Построение идеальной компании.

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

Что такое "качество"? - Это сервис. Сервис для клиента...

10 августа прошло очередное событие от Founder Institute прошло на площадке 404 Hub. В этот раз были компании представляющие финансовый сектор, но важно не из какого сектора компания, а каково их понимание качества у каждой из них.

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

Новые знания? Бесплатно?? В Живую??? - не верю

Кто еще не знает, то  есть инициатива Piter-United - объединение IT сообществ Санкт-Петербурга. И в рамках этих сообществ есть несколько которые могут быть очень полезными для менеджера проектов для развития своих компетенций:

• Клуб Менеджеров проектов связанных с разработкой программного обеспечения SPB SPM Club.  
• AgilePiter  - практики гибкой разработки программного обеспечения. 
• Сообщество аналитиков - CoA

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

Если вы сомневаетесь, "а стоит, ли ?" , а что там? "А вдруг меня там попинают". Не бойтесь.

Применение теории ограничений систем для постановки процессов. (ITGM5)

 

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

Притча об идеальном сотруднике

Ученик пришел к Учителю и спросил
— Учитель скажи, есть ли техники которые помогут мне выбрать правильного сотрудника который мне поможет вести компанию в будущее?

— Никакая методика не поможет тебе - ответил Учитель

— Но как же мне нанять  идеального сотрудника?

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

— Но это же я сам! — воскликнул Ученик — Никто не может так чувствовать меня как я я сам!

— Все правильно, — подтвердил Учитель — Ты не сможешь найти идеального кандидата, но ты сможешь найти что-то приближенное к нему. Однако помни, что если он будет повторять тебя то ты никогда не найдешь прорывного решения для твоей компании.

— Так значит, мне нужно найти сотрудника который будет совсем не похожим на меня? — удивился Ученик.

— Да, он должен быть совсем не похожим на тебя, но при этом быть с тобой на одной волне. — ответил Учитель

— Но как же этого достигнуть? Это ведь не совместимые вещи - воскликнул Ученик, у которого в голове уже все начало путаться.

— Ты сможешь понять это только сердцем — ответил Учитель тем же спокойным тоном и хитро улыбнулся.

А что тут думать? И так понятно что делать.

Выделю из комментария к посту Макса Дорофеева

Все хотят сэкономить время или просто аргументируют этим потому что процесс думания требует больше энергии, если «Мозг, имея массу не более 1,5—2% от массы тела, потребляет 25% всей энергии. " в спокойном состоянии то что говорить о состоянии концентрации в процессе обдумывания решения? Наверное сжирает все 50% энергии.

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

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

1.
-- У меня есть идея и я ее сейчас буду делать.
-- А может ты ее сначала запишешь в вики? 
-- А зачем? Она и так понятна. А я полдня описывать буду. Лучше я сразу нафигачу.
(через 2 дня)
-- Ну как , сделал? 
-- Хм.. что-то я не учел, надо попробовать другой метод.

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


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

Тезисно по моему докладу на ITGlobalMeetup#4: TOC на Agile проектах.

Для тех кто заинтересовался применением критической цепи для проектах по разработке ПО (Agile, XP, иные)  я выложу здесь основные тезисы:

1. Метрики в XP и SCRUM  такие как скорость реализации задач и диаграмма сгорания показывают только ДАТУ когда проект будет завершен но не говорят когда надо договариваться.
2. В голове заказчика все-равно есть бюджет и расписание, даже если вы продаете по Time&Materials. И он не всегда обрадуется увеличению сроков и бюджета в последний момент.
3. Все задачи на проекте можно представить в виде последовательности -  критической цепи.
4. Для критической цепи можно зарезервировать буфер проекта, обычно  1/2 от расчетной  длительности проекта.
5. Контролируя расход буфера можно принять решение о необходимости внесения изменений в план и расписание проекта и необходимости идти к заказчику.

Это может выглядеть так:

по следам ITGlobalMeetup #4

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

• Семена Петкова про Пользовательские и истории и бумажное прототипирование. 
• Евгению Чучмакову про Формирование требований в виде вариантов  использования.

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

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

Из хорошего:

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

Из не очень хорошего:

• Футболка  мне не досталось, когда я собрался ее получить их уже не было %(.
• Домой в одиночестве ехал. Точно никому на ЮЗ не нужно было?

Экспресс-курс «Проектное планирование»

Везде ли применимо проектное планирование?
Любую деятельность компании или отдельного человека можно разделить на два состояния:

1. Я делаю (сделаю) что-то сейчас;
2. Я буду это делать в будущем.

Первое состояние очень популярно в торгово-закупочной деятельности:

• купить прямо сейчас;
• заказать прямо сейчас;
• позвонить прямо сейчас.

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

О внутренних конфликтах

Вытащу отдельно из обсуждения в блоге  Макса Дорофеева.


Внутренний конфликт интересов приводит  перенапряжению и как следствие состоянию "задолбанности" или попытке  сбежать от действий которые требуют какой-то полезной активности.

Но откуда он получается?

Предисловие

В связи с безвременной кончиной Я.Ру где я заводил предыдущий свой технический блог и необходимостью что-то рассказать про свои практики управления проектами и какие-то технические решения из области фантастики разработки ПО, я столкнулся с тем что спамить свой  ЖЖ техническими постами как-то нехорошо.

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

Вот именно такие заметки я и будут размещать здесь.