КаБа

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

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

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

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

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