КаБа

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

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

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

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

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

1. Человек, за которым не надо следить, выполнил ли он поставленную задачу в назначенный срок или нет. 2. Человек, которому можно просто сказать, что надо сделать, а он предложит пару-тройку вариантов, как это сделать и обоснованно предложит наиболее правильный в имеющейся ситуации вариант. 3. Человек, который при получении задачи оценивает возможность ее выполнения в указанный срок и если в имеющейся постановке ее невозможно выполнить в этот срок, то может предложить свои варианты реализации, которые позволят достичь цель в обозначенные сроки. 4. Человек, который понимает, в чем различие между методологией, методом и технологией и умеет пользоваться этим пониманием. 5. Человек, который способен обоснованно выбрать правильные технологии и создать на их основе самодостаточную архитектуру небольшого решения. 6. Человек, который умеет видеть риски для своих задач и предложить варианты их избегания или (если сработали) компенсации последствий. 7. Человек, способный вести за собой неб

Я тут какое-то время назад попытался высказать свое отношение к качеству заказных информационных систем , но в силу ряда причин хочется эту тему немного развить. В двух словах качество ИС – это степень ее соответствия целям Заказчика, а соответственно – его ожиданиям и потребностям. Эти ожидания и потребности удовлетворяются не только функциональными возможностями продукта и совсем не его техническим качеством. В этом проявляется инвариантность качества: тот факт, что продукт совершенно идеально прошел тестирование и ни одной баги не вернулось с прода совсем не говорит о том, что продукт качественный. Легко может получиться так, что методология использования продукта не учитывает специфику процессов Бизнеса, в связи с чем использование продукта попросту не удобно. И Бизнес совершенно справедливо будет говорить о низком качестве ИС. Ему, Бизнесу, совершенно по барабану, сколько багов осталось в финальном билде, добравшемся до прода. Ему важно, чтобы продукт помогал достичь те цели, ко

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

Продолжение… Начало темы тут: Оценка эффективности работы аналитика - предпосылки Если кому-то придет в голову спросить аналитика, чем он занимается. то он получит отличную возможность нарваться на долгий рассказ про процессы as is и to be, сценарии использования, требования, логические модели данных, прототипы пользовательских интерфейсов, шаблоны отчетов, алгоритмы конвертации чего-нибудь в кого-нибудь и т.п. Но ведь это всего лишь перечисление артефактов, над которыми работает аналитик! – воскликнешь ты и будешь совершенно прав. И это не те знания, которые помогут нам понять, как оценить эффективность работы аналитика и по возможности научиться управлять аналитикой не только по планам, но и по фактам.

Уже несколько раз сталкивался с тем, что потенциальный кандидат на обучение / трудоустройство в аналитику на вопрос о том, почему он хочет стать аналистом, отвечает примерно так: "ну тестером как-то стремно, в программисты надо много технических тем подымать, а вот аналитика...". А потому попробую агрегировать основные заблуждения, связанные с моей профессией, с которыми приходится сталкиваться: 1. Аналитика - это увлекательная разнообразная работа, в ходе которой постоянно общаешься с разными людьми, много ездишь, постоянно узнаешь много нового для себя. 2. Аналитик постоянно решает новые задачи, из разных предметных областей и т.п. 3. Когда я стану опытным аналитиком, тогда уж у меня точно будут постоянно новые интересные... (далее смотри п.п. 1 и 2). 4. Работа аналитика не требует технических знаний из сферы технической реализации систем. 5. Позиция аналитика - это очередной шаг в карьерном развитии тестера, программиста, .... (можно еще кого угодно вписать). 6. Аналитик з

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

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

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