Архив за Январь, 2010

Несколько задач на бюджетирование отделов

Четверг, Январь 14th, 2010

Комментарии не буду публиковать в течении двух недель, если автор это обозначил. Свое решение также постараюсь опубликовать по прошествии двух недель.

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

В фирме порядка полусотни человек. Из низ 35 – отдел разработки. Зарабатывают в среднем полмиллиона долларов в месяц, или примерно $10 000 в месяц на человека. Фирма занимается производством софта, тем и живет. Какой это софт: коробочный, заказной, внутренняя разработка в рамках холдинга или SaaS - нам неважно. Важно, что ограничений по рынку пока нет. И можно было бы продавать больше, чем сейчас, но пока выпускать сильно больше не получается. Расширение фирмы стоит в плане, но пока есть то, что есть.

В отделе разработки есть аналитики, кодировщики, дизайнеры, кто-то еще, а совсем недавно создали группу тестирования. Из трех человек. Так получилось, что при организации группы тестирования кто-то где-то чего-то недосчитал, и тестирование стало узким участком. Смотри ситуацию, описанную в статье «Как уменьшить производительность отдела, увеличив численность».   Надо сказать, что подобная ситуация встречается сплошь и рядом, и многие российские фирмы примерно так и работают. Это не было бы проблемой, но Штатное Расписание утверждается на некий период времени (полгода), и изменить штатное расписание сейчас нельзя.

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

Вопрос: Закрыть проект или не закрыть? Насколько отличаются финансовые результаты первого и второго решений?
Необходимые данные для решения.
•    Считайте, что в месяце 4 недели, по 40 рабочих часов.
•    Итого у вас 160 рабочих часов в месяц на человека.
•    Люди не болеют и в отпуск не ходят. И не увольняются. (Допустимое предположение, учитывая, что в реальном бухгалтерском месяце не 160 часов, а несколько больше).
•    Тестировщиков трое.
•    Данный проект требует недели тестирования.
•    Глав маркетолог ошибается с вероятность 20%. 20%  за то, что проект выйдя в свет принесет таки свои 125 тысяч долларов продаж и 80%, что продажи будут нулевые.

Если вам кажется, что данных не хватает, то можете их придумать. Постарайтесь взять относительно близкие к жизни. Например, так:
•    Зарплата каждого тестировщика $2500, а его полное содержание (+ налоги, + офис, +…) обходится фирме в $6000
•    Выкатка релиза после тестирования обойдется в один день кодировщика, с зарплатой в $4000 и полной стоимостью содержания в $8000

Задача 2.
Понятно, зачем вводили тестирование. В продуктах было многовато багов. Сейчас тестировщики находят их аж 600 штук в месяц (каждый примерно по 200). Но уж вычищают так, что потом с продуктами можно работать. Ответственные люди. Молодцы.

Для того, чтобы лучше понять дальнейший материал, посмотрите статью: Почему тестирование занимает так много времени?

Будем считать, что в строгом соответствии с этой статьей, тестировщик посвящает тестированию 4,5*20 = 90 часов времени из общих 160 часов в месяц. Одна ошибка в среднем отнимает 14 минут от этого времени. Что немало.

И один из сотрудников предложил рассмотреть идею о предотвращении ошибок. Действительно, анализ показал, что есть группы похожих ошибок, которые можно было бы не допустить превентивными мерами. Например, можно купить готовый стандарт проектирования GUI, созданный другой фирмой для такой же предметной области. Можно послать аналитиков на тренинг. Можно…  Да много чего можно. Часть действий можно даже сделать бесплатно. Но мы готовы менять дополнительные деньги на уменьшение числа ошибок находимых тестировщиками. (Если честно, то в это я не очень верю. Но чего не сделаешь ради успеха проекта…)

Вопрос в том, насколько это выгодно. Если быть совсем точным, сколько денег выгодно потратить на то, чтобы 100 ошибок в месяц из 600 до тестировщиков не доходили?

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

Задача 3.
Побывав на семинаре о влиянии оснащенности рабочего места на производительность сотрудников, проводимом Александром Орловым, руководство рассматривает возможности переоснащения рабочих мест. Но как вы понимаете, бюджет давно распланирован, и денег можно выделить только на пилотное внедрение. Что, кстати, разумно. В 50% повышение производительности труда никто не верит, но и 20% было бы очень, очень хорошо. Даже 10% - неплохо.

Тестировщики запросили монструозные рабочие станции. С многоядерными процессорами и памятью большей, чем на многих серверах (для создания виртуальных машин). Хорошие мыши и клавиатуры. Плюс куча всего по мелочи. Но не это самое страшное. Они запросили четырех-мониторные ПК. Три монитора – стандартные 17” для проведения конфигурационного тестирования одновременно в трех браузерах и … 24” Samsung 245T (лучший выбор для основного рабочего монитора по состоянию на 2009 год) c PVA матрицей для программ коллективной работы. Под такое рабочее место и стол другой нужен. И новое устройство бесперебойного питания. И… Посчитали – три рабочих места обойдутся в $10 000 (так проще считать). Требования разумные, но десять тысяч…

Естественно инженеры других специальностей возмутились. Архитектор БД давно просил 30” монитор для работы со схемами. Главный аналитик тоже хочет приличное рабочее место, хотя бы с двумя 24” мониторами. И главный маркетолог. И…

Все понимают, что есть различия в квалификации и в оплате труда. И есть разумное предположение, что имеет смысл увеличивать производительность самых высокооплачиваемых сотрудников. Где-то на happy-pm даже была подобная рекомендация. С некоторыми оговорками я с этой рекомендацией согласен.

Вопрос. Как изменятся продажи фирмы если:
1)    Переоснастить рабочие места тестировщиков
2)    Переоснастить рабочие места гл. маркетолога, гл. аналитика и архитектора БД (тоже три места)

Необходимые данные для решения.
•    Считайте, что полезный выхлоп инженеров увеличится на 15%
•    Остальные данные возьмите из предыдущих задач
Если вам кажется, что данных не хватает, то можете их придумать. Постарайтесь взять относительно близкие к жизни.

Проект ненужный полностью

Вторник, Январь 5th, 2010

Совершенно обыденная и очень часто встречающаяся ситуация.

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

Поскольку за вопросы: «А зачем это нужно бизнесу?» - из организации увольняют (тоже часто встречающаяся и совершенно обыденная ситуация), то никто и не спросил. Фаза бизнесанализа была благополучно похоронена.

Системный анализ. Эту стадию естественно пропустили. Действительно, как можно описывать, что нужно сделать, если никто не знает зачем? Абсурд.

Архитектура. Подойдет любая. Совсем любая.  Хотите пишите на коболе под мейнфрейм, хотите реализуйте SOA с декларативно-логической базой данных на модном языке H$ и GUI ориентированном на слепоглухонемых пользователей.
Потом кто-то что-то покодил.

Может даже кто-то чего-то протестил. Интересно, а как можно тестировать «Нечто», если непонятно на что «Это» должно быть хотя бы похоже? Может невозможность создания аккауната это не баг, а фича?! Любите сюрпризы.

И через пару лет работы над этим кадавром ненужном полностью о нем начинают забывать.  А при плановом переходе с CVS на SVN код непонятной этимологии благополучно грохают.

Покойся с миром. Было бы гораздо хуже, если бы тебя выпустили в свет.

Критерии успешности проекта

Понедельник, Январь 4th, 2010

В этой статье предполагается, что заказчик не принадлежит к биологическим видам «Пильщик Бюджета Обыкновенный» и «Карьерист-Паразит Корпоративный».

Часто приводимое определение успешности:

  • В срок
  • В рамках бюджета
  • С заданным функционалом и приемлемым качеством (заказчику понравилось).

Определение Коберна (дано по книге «Agile Software Development» / “Быстрая разработка программного обеспечения»):

  • Проект завершился выпуском продукта. Я не спрашиваю, был ли он завершен в срок и уложился ли в бюджет, важно, что ПО выпущено в свет и начало использоваться.
  • Руководство проектом сохранилось. Руководителя не уволили за то, что он натворил.
  • Команда, работавшая над проектом, собирается таким же образом работать снова.

Это очень разные определения, но есть нечто, что их роднит .
Рассмотрим пример.  Пусть это будет полугодовой проект заказной разработки по внедрению складской системы. Стоимостью проекта триста тысяч долларов.

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

qcedu.PNG
Оба вышеприведенных определения успешности проекта – внутренние. Теперь попробуем дать внешние определения.

Определение конечного пользователя:

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

А что скажет бизнес заказчика? Не будем торопиться. Предположим, через месяц после начала проекта исполнитель делает встречное предложение:

В принципе, мы можем сделать проект, удовлетворяющий всем трем группам критериев. Через 5 месяцев у вас будет требуемый функционал заданного качества, ваши сотрудники будут довольны и наша команда будет рада работать с вами дальше. И проектные риски минимальны. Мы уже двадцать раз все это делали. Но. Мы тут немного посчитали и нашли, что ваш профит от этого проекта – 100 тысяч долларов в год. Что, согласитесь, не очень много. Предлагаем вам другой вариант. Давайте вместо этой системы складского учета мы попробуем написать систему управления складскими запасами. Честно предупреждаем, что риски будут высоки. Почти наверняка:

  • Проект будет тянуться около года.
  • Это будет стоить не менее полумиллиона, но сколько точно мы пока не знаем.
  • Трудоемкость обслуживания новой системы будет выше.
  • Новая система будет сложна в обслуживании и вам понадобится дополнительное обучение.
  • Возрастут требования к квалификации персонала.
  • Скажем честно, есть шанс, примерно в одну четвертую, что мы не сможем сделать этот проект.

Заказчик  подумал, да и согласился.
В итоге:

  • Проект тянулся почти два года (превышение по срокам в 2 раза).
  • Потребовал два миллиона долларов (превышение по бюджету в 4 раза).
  • Система регулярно падает и ее пока «ведут на костылях».
  • Пользовательский интерфейс чудовищен и сотрудники заказчика выражают свое недовольство в простой и понятной форме.
  • Даже возросшая после переобучения квалификация персонала не может уберечь  от мелких досадных ошибок и завсклада носит с собой валокордин.
  • Проект потребовал огромного напряжения от проектной команды. Уволился ПМ и часть разработчиков.

Теперь проект не соответствует всем вышеперечисленным группам успешности. Но вложения отбились через полгода после внедрения, и сейчас система устойчиво приносит порядка пяти миллионно долларов в год бизнесу заказчика.
Был ли проект успешен для заказчика? Видимо да. Значит, мы имеем еще одно определение успешности:

  • Проектные риски были в пределах нормы по отрасли [например, вероятность досрочного закрытия менее 50%].
  • Затраты на проект + совокупная стоимость владения отбились за приемлемый срок [например, год].

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

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

PSS. История про систему учета складских запасов не совсем вымышленная. Она по частям собрана из реальных историй.

PSSS. Есть еще группа критериев, относящаяся к “закулисным заинтересованным лицам”. Но она не так интересна.