Originally posted by alex_aka_jj at Совещание

Пост этот посвящаю семинару PMI на тему «Уроки внедрения эффективных процессов в компании Промедичи». Докладчиком выступал Александр Лесневский, последний директор компании. Доклад был очень спорный. Спорность его дополнительно подчеркивается тем, что я и мой коллега, который был на семинаре – сделали из доклада абсолютно противоречивые выводы. Что, в свою очередь, вызвало некоторую волну флейма в кулуарах нашей компании.

Напишу, какие же выводы сделала я.

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

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

Только продукта почему-то не было. Точнее – было нечто – что стояло у двух клиентов – и то с трудом – были постоянные жалобы. И это за 4 года работы. Любой саппорт и установка очередных билдов – требовали колоссальных усилий.

И тут – непонятно, опять же, почему – материнская компания проснулась и начала выяснять – а почему фигня-то получается. Хотя она сама должна была обеспечить Промедичи и тестовой лабораторией, и стратегией продаж, и видением перспектив развития продукта. Но почему-то – не обеспечила, а руководство Промедичи вполне, судя по всему, устраивала жизнь по принципу «солдат спит – служба идет». А когда такие вещи случаются – кто виноват – конечно же, солдат. Нефиг было спать. И под раздачу пошел ген. директор Промедичи.

Что там было в умах «дальновидного» руководства материнской компании – никому не ведомо, но оно решило пригласить «варяга» - нового гендира, чтобы вытащить продукт из задницы, в которой он находился. Варягом был наш докладчик – Александр. Он, поначалу, толком не разобравшись в ситуации, решил, что он круче всех – и щас всем сделает цимес, но, когда понял, что цимеса не получается, было слишком поздно…

И начались суровые будни.

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

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

И тут встал, как говорится в умных книгах, «ultimate question of life, and universe, and everything», в данном случае – что проще – написать все заново – или использовать старый код. Александру казалось – что проще все переписать, а материнская компания настаивала на переделке архитектуры, но использовании старой кодовой базы. Делать нечего – решили делать на старой кодовой базе.

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

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

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

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

Мои выводы – проект был неживой с самого начала. Александра позвали – на удачу. Да, наверное было 5-10% вероятности проект вытащить, но это сделал бы какой-нить Стив Джобс. Но кабы Александр был Стивом Джобсом – он не работал бы в компании Промедичи. Или надо было ставить потенциального Стива Джобса, который лет на 25 минимум был бы моложе Александра. А так – получилось бы все равно хреново. Если бы Александр продолжал старую политику – да, халява длилась бы еще года два-три – бюджет был бы освоен – но продукта бы не было. Он только ускорил агонию…

В общем – процессы разработки – тут, имхо, совсем ни при чем. SCRUM ли, RUP ли – результат был бы тем же. Роль сыграли гораздо более общие процессы. Корпоративная культура, а точнее, культура отсутствия культуры. И полная некомпетентность материнской компании.

Да, Александр, наломал дров, безусловно – в чем он и не оправдывает себя. С точки зрения материнской компании – он только сэкономил деньги, потому что проект закрыли сейчас, а не через 2 года. С точки зрения Промедичи он – Разрушитель – потому как он изничтожил на корню тот тихий оазис, в тени которого сотрудники в течении 4-х лет наслаждались жизнью…

Вот, так это все вижу себе я. Наверное, я бы тоже поступила так, как и Александр. Не вижу смысла держать «на машинке» пациента, который, по сути, мертв… Реанимация была проведена – не помогло…

Мой коллега, как я его понимаю, принял бы сторону Промедичи – и тянул бы резину до последнего. Что ж, это его путь…

 

 

Вчера на тренинге говорили с Орловым про их со Славой новый проект - Стратоплан - школу тренеров (http://www.stratoplan.ru)

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

А потом я задумалась над этим "не могу - не хочу".

Для меня - всегда - с детства - в силу ли воспитания или по свойству характера - отсутствовало слово "не хочу". Было слово "надо" - а всякие там "не хочу" - для сопляков и слабаков. Единственное, что может быть препятствием против "надо" - это "не могу". И то, сперва надо подумать, совсем-совсем не могу, или просто надо немножко постараться. Если есть хоть малейший шанс - я впрягусь.

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

Это же "надо" - часто мешает мне сказать "нет" - ведь надо, очень надо. Мало ли, что я не хочу - надо - важнее.

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

Всем привет,

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

В эти выходные я была на тренинге "Игры в IT" (http://it-games.ru/), который проводят Саша Орлов и Слава Панкратов.

Тренинг потрясающий - взрыв мозга во всех смыслах.
Посетить - обязательно имеет смысл.

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

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

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

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

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

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

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

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

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

В результате жестоких и кровопролитных холиваров, которые все-таки удалось завершить мирными переговорами - http://kstref74.livejournal.com/14051.html - победили сторонники разбиения адресной строки по полям, причем с большим преимуществом (я просто устроила аналогичный опрос в местном вики плюс поговорила с потенциальными клиентами продукта).

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

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

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

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

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

Соответственно, вопрос,  какие тут могут быть методы воздействия/убеждения/обеспечения качества решения?

1. Дмитриев Сергей - Ретроспективы. Настраиваем наш процесс разработки.
   
   • Живой неформальный доклад, очень понравилось, как докладчик работает с аудиторией. При этом - подача информации понятная и структурная. Многое из этого попробую взять в работу - тем более что то, как проводятся ретроспективы у нас в компании меня, мягко говоря, не устраивает. Что лично для меня было ключевого в докладе - промежуточные ретроспективы по итогам фаз или спринтов проекта. Обычно слышала или читала только про ретроспективы по итогам релизов. И второе - при обсуждении проблем, выявленных на ретроспективы - не обсуждать второстепенное (а то у нас обычно считается, что надо обсудить все наболевшее) - а тут как с бэклогом - надо выявить самое наболевшее + решаемое - и с ним работать. Плюс к этому, не переходить сразу от проблемы к поискам путей решений, а попытаться выявить корневую причину проблемы - это может в корне изменить подход к решению. А наши люди тоже свойственны сразу кидаться в бой.
2.  Бережной Сергей - Разработка ПО как сервис. Фокусируемся на Заказчике
   
   •  Ожидала от доклада большего. Насколько я поняла из последующего обсуждения к коридоре, не только я. Возможно, просто доклад рассчитан на другую целевую аудиторию - на начинающих менеджеров, только-только оторвавшихся от решения технологических проблем и сфокусированных исключительно на технологичности представляемых решений. Для любого более-менее зрелого менеджера, да который, к тому же, общается с заказчиком не из IT сферы все вещи, о которых говорилось в докладе - в некотором роде азбучные истины. Ниже в посте у меня еще будут лирические отступления на тему данного доклада.
3. Георгий Ковалев - Внедрение практики управления проектами в Лаборатории Касперского
   
   • Мне понравилось. Мы у себя тоже пытаемся что-то сделать как с процессами компании, так и проектным управлением - поэтому было очень интересно послушать про смежный опыт. Работа проделана огромная - и результаты - и пути их достижения - интересные. Жаль, что не было Александра Самбука - он заболел - поэтому не было общей картинки "Проектное управление - Процессы компании - Продукты компании", Георгий рассказывал только про свой кусок - проектное управление. Интересен сам подход к проекту - начался просто потому, что так захотело начальство, ROI не меряют и это даже не стояло в задачах - только сейчас они приходят к тому, что есть возможность получать некие метрики и начать считать ROI. Подход к обучению - учат "по факту" - т.е. не как многие "у нас вот тут скоро будет переход к проектному управлению - давайте поучимся" - а именно в рамках внедрения проектного управления и даже более, инструментариев для его ведения - учат людей пользоваться инструментами - и попутно дают общие навыки. Как борятся с тем, что регламенты никто не читает - вместо регламентов рисуют комиксы.
4. Башакин Дмитрий - Ситуационное управление – опыт практического использования в ИТ-проектах
   • Абсолютно новый для меня материал - никогда ничего на тему не читала и не слышала. В целом, конечно, как и любая модель - попытка впихнуть невпихуемое - но интересно. Потому как если не пытаться впихнуть - то работа превратится в хаос. Митя рассказывал живо и интересно - но материала явно больше, чем времени - отведенного на его подачу - поэтому он явно гнал лошадей. Подумаю на тему посещения соответствующего тренинга - но уже явно не в этом году. По этому докладу тоже будет лирическое отступление ниже
5. Стив Макконнелл - Как сделать эффективным процесс разработки ПО?
   • Самое большое разочарование. Интересно - человек русских считает идиотами - или он вообще зазнался - и всех считает идиотами? Потому что доклад - полная халтура - все те данные и цифры - которые приводились - можно найти на любом перекрестке в интернете. И когда ему об этом в мягкой форме намекнул один из слушателей - он еще и обиделся. В докладе не было ни одной свежей мысли - да вообще мысли не было - он просто пересказал слайды с цифрами. Когда пытались задавать какие-то вопросы более конкретные - фактически уходил от ответа. Вывод - для - организаторов конференции - может - не гоняться за дешевизной и "звезд" не приглашать? Потому как когда идет замануха на звезд - а потом эти звезды несут пургу - то впечатление куда худшее, чем если бы звезд не было совсем. Ну или как-то надо делать "ревью" того, что эти звезды собираются доложить, объяснить им, что у русских есть интернет и они даже его читают - и книжки они тоже умеют читать, как ни странно. Перевод - лично мне только мешал. Переводчица явно не владела технической терминологией - со всеми вытекающими. Имхо, стоит попробовать разориться на аппаратуру для синхронного перевода - тем, кому надо перевод - будут слушать его, а остальным хоть этот перевод не будет мешать - и сам доклад пойдет живее.

Лирическое отступление

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

1. Сергей Бережной в качестве примера сфокусированности не на заказчике, а на себе - привел пример банка, который отказал ему в перевыпуске карты с изменением срока ее действия. Народ тут же кинулся обсуждать - какие в Украине дурацкие банки - и что быть такого не может. Пример неудачный, имхо, с двух позиций.
   • Во-первых, что действительно - ситуация спорная. И что можно было бы подумать о примере, который не допускает неоднозначных трактовок. Я предложила в качестве замены банку - любое подразделение служб ЖКХ - тот же ЖЭК - и все сразу согласились с тем, что все, что там делается, даже не пахнет сфокусированностью на заказчике. 
   • Во-вторых - случай с банком заставил меня задуматься - а так ли и не прав был банк, отказав. И не был ли его отказ мотивирован именно сфокусированностью на заказчике. Ведь для банка один из основных компонентов сервиса - безопасность. И одним из основных средств обеспечения безопасности - является следование процедурам и регламентам. И любой выход за рамки регламентов - ставит под угрозу безопасность - причем не только этого клиента - но всех. И объяснить это клиенту в доступной форме - в общем-то - нереально - и получается что для данного конкретного клиента мы нарушаем принцип сфокусированности на нем, сохраняя при этом глобальную сфокусированность на заказчике. Это такой, как мне кажется, важный момент в проблеме "фокуса".
2. Митя Башакин, когда рассказывал про модель Кена Бланшара и приводил примеры уровней развития (Неопытный энтузиаст - Разочарованнй новичок - Осторожный эксперт - Профессионал) - в качестве примера рассказывал, как он учил кататься на велике свою дочь. И тоже народ сразу начал обсуждать сам процесс обучения езды на велике, что мальчики учатся так-то, девочки так-то, и что было бы, если бы сперва она каталась на 3-х или 4-х колесном велике - короче, народ зацепился за краевые условия. Я тоже думала - а чем можно пример заменить - и тоже придумала вариант.
   • Во-первых велосипед в проекции на IT - не есть хорошо. Велосипед - это такое нечто очень физическое - сродни тому, что мы учим забивать гвозди или что-то такое - фактически - процесс обучения сводится к получению неких сугубо физических навыков. Поэтому стадии как руководства так и прохода человека по стадиям несколько иные. То есть пример может и визуально понятен - но на IT ложится плохо - ведь мы не учим разработчиков долбить по клавиатуре свободным 10-пальцевым методам, пользоваться код-комплишеном и так далее. Мы пытаемся их учить думать и находить решения. Как мне кажется. :-) И аудитория сразу спроецировала велосипед на IT и поняла - что не все гладко - поэтому уехали мы на этом велосипеде немного в сторону.
   • И стала я думать, а что такого более-менее понятного всем можно придумать - того, что было бы связано именно с мыслительной деятельностью. То есть того, где мы как-бы учим - но это нам кажется - мы не можем в реальности держать этот велосипед - как бы нам этого не хотелось. В нашем случае человек реально с самого начала едет сам - мы только соломку стелим. Ну и надумала из той же детской области. Ведь когда мы учим ребенка писать (не читать, читать - это просто и интересно - а писать - это нудно, надо выводить идиотские прописи - и так далее) - мы не можем писать за него. Водить его рукой - нет - это не поможет, его мышцы не окрепнут  - крючочки не станут ровнее. Он должен пройти через все эти крюки-закорюки сам - и любой родитель скажет - сколько это слез и истерик. И тут мы реально имеем все стадии развития и огромную проблему в выборе стиля руководства. Как мне кажется, во всяком случае. Тут тему можно даже развить - ребенок хочет писать слова (разработчик горит желанием проектировать архитектуру) - а должен выводить крючочки (сидит на багфиксе или пишет простые классы, которые потом по 5 раз ему возвращаются с ревью). :-)
   • Перечитала - тоже, в общем-то крючочки не сильно лучше велосипеда - физическое же действие. Можно попробовать вместо крючочков объяснение задачки - подходов к решению, упрощению - мы с мужем потратили довольно долго времени, объясняя сыну, что чем складывать, умножать/делить или вычитать числа в лоб (особенно большие) - надо посмотреть, может, раскрыть скобки или порядок действий можно изменить так, что это будет сделать гораздо проще и быстрее. И видеть это - реально нельзя научить физически - тут надо что-то чтобы в мозгу перещелкнуло - а где у него кнопка - мы не знаем. :-)
   • В общем да, найти пример, который наглядно иллюстрирует теорию, да еще и хорошо ложится в предметную область целевой аудитории - нетривиально.

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

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

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

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

Вопрос такой - как писать адрес клиента?
1. Все одной строкой, как если бы мы письмо писали от руки
2. С разбиением по полям: улица - дом - корпус/строение - квартира - прочее (подъезд, этаж, домофон и так далее)

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

Poll #1645574 Служба доставки - адрес клиента
Open to: All, detailed results viewable to: None, participants: 9

Как лучше (правильнее, удобнее) вводить адрес клиента службы доставки?

Уважаемые читатели моего блога,

Я тут немного помогаю Гильдии Менеджеров Программных Проектов (www.spmguild.org) и Клубу Успешных Менеджеров Программистов (www.happy-pm.com) в проведении исследования успешности программных проектов.

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

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

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

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

Ссылка на он-лайн анкету:
http://spreadsheets.google.com/viewform?hl=en&formkey=dDROVjZfNmZGeGVac01idG8xdExxbWc6MA

Краткие рекомендации по заполнению:

Очень хотелось бы, чтобы вы заполнили ее, с одной стороны, быстро, с другой, внимательно, с третьей - честно. Приведу цитату из объявления на www.happy-pm.com:


Более подробная информация об исследовании:
http://www.happy-pm.com/blog/?p=3681
http://www.happy-pm.com/blog/?p=3930

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

На семинаре говорилось о том, какие факторы в ту или иную сторону влияют на производительность программистов.

В общем, лучше всего Саша рассказал про свой доклад сам в своем блоге http://www.happy-pm.com/blog/?p=3665, там же можно найти слайды презентации.

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

Саша еще раз рассказал всем то, что у любого менеджера должно быть на лбу нарисовано красным: про состояние потока, в котором программист работает наиболее эффективно и про то, что на вход в это состояние требуется от 15 до 30 минут. И что надо 10 раз подумать, прежде чем подходить к своему инженеру и спрашивать: «Ну как там бага фиксится?». В качестве таких вот явлений, выводящих из потока, упоминались: почта, мессенджер, совещания, бешеный менеджер. Бешеный менеджер стоял на последнем месте, хотя я бы поставила его на первое, потому что все остальное поддается регулированию.

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

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

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

Коллеги,

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

Есть две основных теории:

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

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

Какие имеются ограничения. В первую очередь, хотелось бы иметь бюджетное решение. Вбухивать бабки в систему а-ля BMC Remedy или HP OpenView никто не готов. Во-вторых, хотелось бы иметь решение, которое начало бы работать как можно быстрее. В третьих, хотелось бы иметь решение, которое было бы легко поддерживать.

Что еще могу сказать. Как сам продукт, так и служба техподдержки довольно молоды и находятся на стадии становления. Клиентов пока не настолько много, чтобы техподдержка представляла собой что-то монументальное. Но уже достаточно, чтобы наколеночные решения не работали. О колл-центре пока речи не идет, о регистрации обращений через интернет - возможно, но 99% обращений поступает в виде телефонных звонков. Основные пользователи нашего продукта (не системы HelpDesk) - люди, от IT далекие. В HelpDesk вообще пользователям доступа давать не планируется. Всегда на входе прокси в виде нашего оператора хелпдеска. Когда говорится о возможности заведения инцидентов через интернет, имеется ввиду, что система может автоматически отправлять сообщения об ошибках, если произошло обрабатываемое падение.

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

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

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

Poll #1489701 Организация техподдержки
Open to: All, detailed results viewable to: None, participants: 16

Как должны быть организованы системы техподдержки и багтрекинга