255 ступеней

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

Cуществуют несколько подходов:

1. Кончились деньги на тестирование.
2. Найдены и исправлены все дефекты (я не знаю, как это сделать) .
3. Выполнены все запланированные тесты и не осталось ни одного активного дефекта с важностью «Критично».
4. Обеспечено разумное тестовое покрытие (любым способом) и совокупность активных дефектов признана допустимо хорошей (согласно утвержденного регламента) для передачи в эксплуатацию.
5. Кривая активных дефектов четвертый раз была равна нулю (любопытный метод от Microsoft).
6. Экспертное мнение опытного (стаж в коммерческой разработке ПО от 10 лет) инженера по качеству.
7. Отсутствие или допустимое число замечаний по итогам приемо-сдаточных испытаний
8. Оценка числа невыявленных дефектов и уровня дефектности программного модуля признана удовлетворительной на основании проведенных статистическими исследований:
   a. Частичного перекрытия зон тестирования
   b. Искусственной вставки известного числа дефектов в тестируемый код
   c. Выборочного исследования

Экспертное мнение дешевый и часто самый надежный метод оценки готовности. Но ему не так часто верят. Действительно, а факты где? Чем доказать, что софт не готов?

Я предлагаю еще один метод анализа.

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

Причина первая.  «Приминать траву» можно до бесконечности.  Всегда можно придумать еще одно улучшение и оформить его как дефект.

Причина вторая. Основное время тестирования уходит на описание дефектов.
Пройдете вы за неделю 50 или 1000 сценариев – все равно в среднем вы опишите примерно одно и то же число ошибок (30-150 в зависимости от проекта).

Таблица 1  Число найденных ошибок понедельно в разрезе критичности
 
Если построить понедельный график количества найденных ошибок, то получится что-то такое:
 
Рисунок 1. Число найденных ошибок по неделям

 Для анализа не годится.
Но можно построить точно такой же график с разбивкой по важности (не стоит использовать приоритет). Кстати именно для такого анализа имеет смысл вести два атрибута: критичность и приоритет. Приоритет нужен для управления, критичность для статистического анализа.
 
Рисунок 2. Число найденных ошибок понедельно в разрезе критичности

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

Следующий шаг состоит в «приведении к общему знаменателю» дефектов с разным показателем важности. Нужно придумать функцию, которая будет использовать веса приоритетов. Хороший вариант был предложен Тагути (смотри «Функция потерь Тагути»)
В соответствии с этой функций зададим веса:
• Critical - 16
• Major - 9
• Average – 4
• Minor – 1

Следующий шаг – нормирование на трудозатраты. Число найденных ошибок сильнее всего зависит от того, сколько часов из 40 мы уделили тестированию. Влияние трехдневной болезни очень велико.

Можно вести учет времени, но это трудоемко и точность оставляет желать лучшего. Гораздо проще отнормировать на число найденных ошибок за период. Таким образом, мы в чистом виде получим изменение характера ошибок.
 
Рисунок 3.  Профиль критичности

Достаточно типичный  результат. Первое время идет рост. Это время знакомства с функционалом.

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

Значение между единицей и четверкой говорит о хорошем состоянии проекта. Глядя на этот график я предполагаю, что после десятой недели тестирование можно прекратить. Для определенной категории проектов.  А если брать проекты с низкими требованиями к бездефектности вроде wordpress, то и восьмая неделя была явно лишней.

У этого метода анализа естественно есть ограничения в применимости. К ним относятся:

• Разнесение во времени разных видов тестов. Так тестирование ссылочной целостности выявляет множество критичных ошибок, но может идти после тестирования базового функционала.
• Разные участки программы делали программисты с резко отличающимся опытом.
• У вас не накоплено статистически значимое количество исходных данных.
• И т.д. и т.п.

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

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

В системах энтерпрайз уровня подобная анатлитика есть. Так например, Rational Clear Quest имеет встроенный и очень неплохой генератор отчетов. Вот этот отчет был получен в Rational Clear Quest почти честным способом. Почти, потому что SQL запрос пришлось таки допиливать вручную.
 
Рисунок 4. Число найденных ошибок понедельно в разрезе критичности. Отчет ClearQuest.

Другой вопрос, и он самый важный: ”Будете ли вы делать такой анализ?”

Приложение 1. SQL запрос для получения графика в CQ.
select distinct cal.start_date,count(T1.severity) as record_count,T1.severity from weekcal cal,Defect T1 where (cal.start_date >= #2000-01-10# and cal.start_date <= #2001-01-01#) and (T1.submit_date >= cal.start_date   and T1.submit_date <   cal.end_date) group by cal.start_date,T1.severity order by cal.start_date, T1.severity

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

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

В фирме порядка полусотни человек. Из низ 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%
•    Остальные данные возьмите из предыдущих задач
Если вам кажется, что данных не хватает, то можете их придумать. Постарайтесь взять относительно близкие к жизни.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот характерный пример дискуссии :

- Интересует следующий вопрос - может ли человек, которая не является программистом быть IT менеджером, т.е. фактически руководить программистами?
- Из программистов обычно получаются не очень хорошие менеджеры. И чем лучше программист, тем хуже будет менеджер.
- А вот, кстати, что думает по этому поводу товарищ Джоэл:

Смотреть, как непрограммист пытается управлять софтверной компанией — всё равно что наблюдать за новичком-серфингистом.
«Всё отлично! У меня на берегу отличные помощники, которые подсказывают мне, что нужно делать!» — говорит он и снова падает в воду. Типичное поведение администратора, считающего управление универсальной функцией.

Есть у меня серьезные подозрения, что коллеги на форуме под словом “программист” подразумевают инженера умеющего (пишущего) код и не делающего (не знающего) ничего, кроме написания кода. И именно поэтому коллеги с форума говорят, что человек, разбирающийся в системном и бизнес анализе, в архитектуре и верификации качества ПО на посту менеджера будет смотреться лучше кодера. Джоэл Спольски же явно под термином разработчик  имеет в виду в том числе и Гейтса. Который на описываемый момент имел отличные навыки системного и бизнес анализа, построения архитектуры ПО. И вполне возможно, что к этому моменту Гейтс не писал код уже многие годы.
Попытка увеличения производительности за счет узкой специализации сыграла с нами злую шутку. Но вопрос не в этом. Вопрос в том, что понимать под термином разработчик и что понимать под термином программист. Чем дальше, тем больше инженеры, именующие себя «разработчик/программист» отказываются от проектирования и создания GUI. От верификации и  анализа во всех его проявлениях отказ произошел еще раньше. Происходит постепенное выделение работ, связанных с разработкой БД в отдельную специальность. Но окончательно  добило меня известие о том, что ныне (в одной из фирм) инженеры, называющие себя «архитекторы» отказываются от разработки, верификации и описания API, отдавая это инженерам, именуемым «Системные аналитики». Себе “архитекторы” оставляют выбор языка реализации и написание кода. Как по мне, так это не совсем архитекторы. И не совсем разработчики. И даже не совсем программисты. А, скорее, обычные кодеры. Хорошая профессия. Без обид.

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

Пусть некая фирма занимается разработкой вебпортала. Основные виды работ:

Мое предположение:
1)    Те, кто занимаются только написанием кода – “кодировщики”
2)    Те, кто занимаются всеми или большей частью работ в секторе, выделенном пунктирной линией – “программисты”. Какой же программист не может проверить требования или свой собственный код? Это не программист. Это кодер.
3)    Термин “разработчик”. Здесь, пожалуй, самое сложное. На мой взгляд, под этим термином следует понимать всех людей выполняющих какие либо виды работ по разработке портала. А их отличие от обычных узкоспециализированных специалистов вроде кодировщика, аналитика, верстальщика, копирайтера – то, что они выполняют несколько видов работ.

На семинарах довольно часто всплывает упоминание о трудностях взаимопонимания членов команды с разным культурным контекстом.  Приводят примеры о паттернах поведения индийских инженеров (нельзя высказывать критику в присутсвии руководителя), американских, русских, китайских. Как будто для недопонимания необходимо, чтобы участники общения были из разных культур! Мне вспомнился эпизод из книги О. Брэдли “Записки солдата” (смотри главу 9. “Вторжение в Сицилию”).

- Джордж, - сказал он, - позвольте мне дать вам совет. Если вы получаете приказ от группы армий, который вам не нравится, не выполняйте его. Я именно так и поступаю.

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

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

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

PS. Кайдзен – это почти полностью советская разработка. Так по крайней мере говорят японцы.

В очередной раз увидев на слайде кастрированный график, решил восстановить справедливость. Вот так он выглядит у Коберна в книге  “Быстрая разработка программного обеспечения“:

Удивительно, но очень многие IT-специалисты эту книгу не читали.  Эта книга о подходе к внедрению различных методологий и о их ограничениях. Почему и когда не пойдет SCRUM, выбор между “информационными сквозняками” или “тихая гавань”, общие принципы создания методологии…

Очень рекомендую прочитать эту книгу перед тем как внедрять, а тем более адаптировать новую методологию в вашей команде. Вернее не так. Если у вас перед внедрением XP будет выбор чтения между Беком и Коберном, то читайте Коберна.
PS. Похоже в магазинах этой книги осталось всего ничего. Я бы на вашем месте поспешил.

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

Первая партия разумных советов:

1. С какой стати платить сотруднику больше, чем по рынку? Разумно? Еще как!
2. Нужны командные игроки. От тех, кто некомандный надо избавляться. Тоже разумно.
3. Бизнес должен минимизировать расходы. Тут даже говорить нечего, как разумно.
4. Бизнес принадлежит тому, кто платит бабло. Не просто разумно, но и понятно.
5. Совершенно нормально и правильно резать косты. Т.е. избавляться от балласта, который хочет больше, чем приносит пользы сейчас. Прошлые заслуги никого не интересуют, бизнес живет сегодняшним днем. Архиразумно.

Представим себе, что некоторый человек, пусть это будет Вася, убедил инвесторов, что интернет стартап это круто и там можно поднять бабла. Или что IT это круто. Или что наноГЛОНАСо-Автовазо это круто. Или это инвестор нашел Васю. Неважно.

Важно то, что Инвестор дает денег. По $100 000 каждый месяц, в течение года. Не круто, но вполне жизнеспособно. В полном соответствии с советом #4, проект и фирма принадлежит инвестору. Рассмотрим два варианта развития событий.

Проект неуспешен. Есть еще один очень, очень разумный совет:

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

Обычно после этого решения инвестиции еще продолжаются. Их могут порезать, могут наоборот увеличить, но еще на полгода – год агонии рассчитывать можно. Согласно #6, Васе нужно спрыгнуть с лодки через 14-18 месяцев после начала проекта. В этом случае он уходит сам, как руководитель нормального проекта. Будет тянуть – его уйдут и хорошо, если без записи последствий в трудовой книжке, а так же в грудной, но уже не книжке, а клетке.

Вариант второй. Проект успешен.

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

7.    Избавьтесь от тех, кто привел вас к успеху, сразу, как только найдете, кем их заменить.

Согласно #7,  Васе нужно спрыгнуть с лодки через 14-18 месяцев после начала проекта. В этом случае он уходит сам, как руководитель нормального проекта. Будет тянуть – его уйдут и хорошо, если без записи последствий в трудовой книжке, а так же в грудной, но уже не книжке, а клетке.

Но Вася то командный игрок! Он играет по правилам бизнеса и его цель как командного игрока –это получить через 14-18 месяцев максимально оплачиваемую новую работу в другой фирме. Дабы максимально соответствовать потребностям бизнеса Вася по крупицам выискивает разумные советы. В результате многолетнего мониторинга рынка труда (чтение текстов вакансий) его кладезь мудрости огромный, как барханы Сахары, пополняется следующим набором советных разумностей:

8.    Руководитель получает примерно на 30% больше, чем самый высокооплачиваемый из его подчиненных. Каждый новый уровень иерархии между должностью руководителя и нижним звеном увеличивает коэффициент.
9.    Бизнес ищет руководителей ранее занимавших аналогичные должности.
10.    Бизнес ищет руководителей руководивших N+ людьми.
11.    Бизнес НЕ ищет руководителей успешных проектов, приносящих от $500 000 в год в расчете на инженера. А нафига они? Истинная заслуга такого успеха естественно принадлежит тому, кто платит бабло. Смотри #4.

Ну, вы сами-то вакансии руководителей читали? На hh.ru там, или еще где.

Согласно ##8, 9, 10 и 11  Васе нужно в течение года подняться максимально высоко по иерархии и получить в подчинение максимальное число людей. Полагаю, это очень разумный вывод наемного работника из очень разумных советов владельцев бизнеса.

Как командный игрок, Вася должен нанимать начальниками только командных игроков (смотри разумный совет #2), которые тоже прислушиваются к разумным потребностям бизнеса.

Естественно народу не нужна простая, примитивная как лопата и очень эффективная структура фирмы, где 4-7 инженеров непосредственно подчиняются Васе. Народу  нужно построить примерно следующее:

Уровней иерархий достаточно и многие хорошие, правильные люди получат хорошие правильные должности. Хорошо и правильно звучащие. И через год займут хорошо и правильно звучащие должности в других фирмах. А вот число сотрудников подкачало. Всего-то две дюжины. Но это легко поправить, если воспользоваться разумными советами. ##1 и 2.  При разумном подходе к кадровой политике на эти деньги можно нанять… До дюжины дюжин человек. Конечно, проект после этого гарантированно подохнет. Но Вася дал клятву беззаветно следовать разумным советам. Ради этого он готов даже пойти на жертвы. И даже пожертвовать каким-то проектом. Кому он вообще нужен то (смотри #11)?

Любопытный читатель может спросить: «Встречал ли автор примеры вышеописанного?» Здесь автор отсылает читателя к научной гипотезе о том, что в мире так или иначе всегда реализуется любая ситуация, при условии, что человек может ее себе вообразить. Кстати. Ситуации прямо противоположные вышеописанным точно встречаются. Ну и сами понимаете, что в зависимости от смены контекста разумные советы могут перестать быть разумными.

Буду проводить 24 декабря.

Как правило, группа тестирования выдает «на гора» только два артефакта. Это заключение о качестве программного продукта, также называемого «Отчет о тестировании» и список расхождений между ожидаемым поведением и действительностью, также называемых описанием дефектов.
В отличие, от документации, которую как известно можно и не читать, описание дефекта будет прочитано как минимум еще одним человеком. Тем, кто будет исправлять дефект. Дефект это болезнь программы, исправление – лечение. И чем точнее диагноз, тем проще провести лечение.
В смоем вебинаре по выбору и настройке BTS, я коротко рассмотрел группу описательных атрибутов. В этом семинаре я рассмотрю их подробно.

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

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

Кому адресован тренинг?
В первую очередь тестировшикам (примерно до 5 лет опыта). Во вторую очередь людям, занимающимся подбором тестировщиков.
Условия участия в семинаре

Первая. Документация не больно то и нужна.

Представим себе небольшую команду разработчиков, занимающихся автоматизацией машиностроительного завода. Часть софта покупают, часть пишут сами. Семен Владимирович пришел на завод работать программистом в 1981 году. Остальные в 1988, 1993 и 1997. Самый молодой из разработчиков работает в команде последние 12 лет. Понятно, что в таких условиях все разработчики прекрасно знают операционную среду, заказчиков, пользователей и код. И вся документация на новую фичу трудоемкостью в два человеко месяца может умещаться на одном стикере.

Я предлагаю три метрики:

• Средний опыт разработчиков. В данном случае это 19+ лет.
• Средний опыт работы вместе. (21+16+16+12+12+12)/6= 15 лет
• Средний опыт работы в предметной области

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

Причина вторая. Некому писать.

Действительно, грамотно описать функциональные требования или глоссарий (я уж не говорю про нефункциональные или, тем более, концепцию), это гораздо сложнее, чем закодировать. В результате, вместо требований, которыми можно пользоваться получается скучнейшие “материалы 35 съезда” изложенные косноязычным тинейдрером, знающего только олбОнский, и то с пятого на десятое. Читать это невозможно. Документация становится Write Only. И, в конце концов,  от написания документации отказываются.

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

Причина третья. Команда не умеет читать.

А вот эта проблема по настоящему серьезная.

Типичный пример того, что никто не умеет читать документацию это фразы вида: «Цель проекта внедрения BTS Jira является автоматизация учета багов.»

Я понимаю, у аналитика писавшего ЭТО был неудачный день. Может зубы у ребенка резались и была бессонная ночь. Может быть гриппом болел и голова не соображала. Но то, что из всей команды никто не сказал “Булшит!”, это показатель неумения читать. Писать документацию в этом случае бесполезно.

Проблему усугубляет странная российская система подбора персонала, когда на место разработчика ищется инженер со скилами кодера. Вот типичнейший пример:

Разработчик Java
Требования:

* Обязательные:
Опыт разработки на Java, знание ООП;
Знание  HTML;
Знание и опыт работы с JSP;
* Желательные:
Опыт работы с каким-либо web-framework’ом (JSF, Struts, GWT, Wicked и т.д.);
Опыт работы с какой-либо AJAX-библиотекой (jQuery, Ext-JS, Prototype);
Опыт работы со Spring framework;
Опыт работы с  JDBC, JPA, Hibernate и подобными средствами (взаимодействие с БД);
Опыт работы с WebShpereAS;
Опыт работы с СУБД Oracle;
Опыт работы с EJB;
Опыт работы с Web-сервисами.

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

Проводя курсы по написанию документации, я сделал вывод, что на то, чтобы научить инженера с пятилетним опытом написания кода читать документацию нужно 80-160 часов тренингов. Писать спецификации он после этого будет плохо, а вот читать вполне сможет.