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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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)?

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

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

Представим себе небольшую команду разработчиков, занимающихся автоматизацией машиностроительного завода. Часть софта покупают, часть пишут сами. Семен Владимирович пришел на завод работать программистом в 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 часов тренингов. Писать спецификации он после этого будет плохо, а вот читать вполне сможет.

Начну я с короткого экскурса в историю сестер милосердия .

Флоренс Найтингейл разработала собственный метод, который был максимально прост и максимально эффективен:

• чистота,
  
• свежий воздух,
  
• хороший уход,
  
• режим питания.
  

И все это начало творить настоящие чудеса.…

 В октябре 1854, в период Крымской кампании, Флоренс вместе с 38 помощницами, среди которых были монахини и сестры милосердия, отправилась в полевые госпитали сначала в Скутари (Турция), а затем в Крым. Последовательно проводила в жизнь принципы санитарии и ухода за ранеными. В результате менее чем за шесть месяцев смертность в лазаретах снизилась с 42 до 2,2%.

 Википедия и http://www.marfa-ka.ru/publ/1-1-0-34

Я далек от мысли, что мне удастся сформулировать принципы, благодаря которым “смертность” проектов уменьшится до двух процентов. Но и в два раза было бы замечательно.

1. Нет концепции - нет проекта.

Перед проверкой наличия концепции из нее должны быть удалены обороты-паразиты: “очевидно”, “это нам почти ничего не стоит”, “сокрушительный успех”, “огромное значение для нас”, “развитие стратегического направления” и прочее. Если после этого от концепции осталось менее 50% - можно считать, что ее нет (нужно писать заново).

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

Что делать, если концепции нет, а проект запущен? Если вы болеете за судьбу фирмы, у вас есть следующие варианты: написать концепцию самому или  саботировать проект (шучу).

Дополнение. Развивая предыдущую мысль до маразма, имеет смысл штрафовать руководителя, пытающегося запустить проект без концепции и выдавать премию стукачу. Совет идиотский, но отражает моё мнение о значимости этого инженерного документа.

Что делать, если никто не умет писать концепцию? Это означает, что у вас нет человека, способного выполнять роль “Управляющий продуктом (product manager)”. А что будет, с софтверным проектом, если, например, у вас не найдется людей способных писать код? Загнется? Так без концепции он загнется еще вернее. Найдите того, кто умеет. Можно на работу по договору. Такие люди точно есть. Даже, как ни странно, в России. Я точно знаю, что есть. Я с ними даже общался.

2. Нельзя делать оценку трудоемкости до оценки прибыли.

Этот момент, скорее всего, вызовет массу споров.И все таки, советую действовать именно так.
Во первых, оценка дохода  дешевле оценки трудоемкости, во вторых, если доход нулевой, то зачем оценивать трудоемкость?

Приведу аналогию со строительством. Для того чтобы оценить стоимость (осметить проект) нужно потратить 3% от стоимости проекта на осмечивание. И 15% до  этого на проектирование. Т.е. нужно потратить почти пятую часть бюджета только для того, чтобы узнать стоимость проекта. А грубо оценить продажи квартир в 300-квартирном доме на острове Пасхи можно. Стремятся к нулю. На острове Пасхи проживает всего 3,7 тысячи жителей.

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

Вредные советы.

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

PS. Вышеизложенное сформулировано под впечатлением статей Ашманова.

По мотивам и в продолжении Менеджер по борьбе с персоналом., а так же в продолжении цикла статей Владислава Балина “Защита от темных исскуств”

В некой фирме
Может даже UmaNetto.
Появился вдруг сотрудник
По борьбе работе с персоналом

Чтоб ценить не перестали
выпускает циркуляр он
что трудиться нынче нужно
лишь регламенту согласно.

Разославши сей документ
По отделам бродит нынче
Очень строго наблюдая
Чтоб соседу не помог ты.

Долго, нудно вычисляет
КТУ и KPI
Чтоб потом цифирь зарплатна
Была сразу всем понятна.

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

Предположим, что в софтверной фирме ввели жесткое  правило следования инструкции и привязали зарплату к метрикам.

В январе к техническому писателю подошел маркетолог.

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

Февраль. Техпис остался без премии. К тестировщику подошел программист и спросил:

- Я слышал ты в прошлом проводил исследования на время отклика при разных вариантах организации деревьев в БД?
- Проводил. Но если я буду об этом рассказывать вместо тестирования, меня лишат премии.

Наверное, Саша Орлов сделал бы из этого “пятничный кейс”: “Как инженерам и премии сохранить и пользу фирме принести”.

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

- Программист. И что думаешь?
- Тестировщик. Да есть одна мысль. Поможешь?
- Не вопрос.
- Тогда иди, пиши письмо.

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

От. Программиста
Кому. Руководителю разработки
Копия. Руководителю тестирования
Требуется помощь тестировщика <имярек> для принятия решения о выборе архитектуры.

От. Руководителя разработки
Кому. Руководителю тестирования
Копия. Программисту
Это позволило бы существенно сократить время проекта и уменьшило бы проектные риски.

От. Руководителя тестирования
Кому. Техническому директору
Копия. Руководителю разработки
Согласен с коллегами.  Но это противоречит инструкциям. И нам очень не хочется остаться без премии, как это уже имело место быть.
От. Технического директора
Кому. Генеральному директору
Копия. Руководителю программирования, Руководителю тестирования
Тщательного рассмотрев проблему я пришел к выводу, что ситуация может развиваться по следующим сценариям:

1. Оставить как есть. Сроки проектов будут срываться, а проектные риски взлетят до небес. Полагаю, на то чтобы угробить фирму нам понадобится 6-12 месяцев.

2. Разрешим нарушение Инструкции конкретно в этом случае. Но подобные решения нам придется принимать по десятку раз в день. Что не очень эффективно.

3. Изменим инструкцию тестировщика. В связи с расширением должностных обязанностей, согласно  ТК РФ, увеличим оклад. И будем поступать так каждый раз, пока все не придет в норму.
4. Переоценим решение о зависимости зарплат и выполнении должностных инструкций. Техническому писателю принесем официальные извинения и  начислим январскую премию в феврале.
В хорошей фирме, способной исправлять последствия неправильных управленческих решений все будет хорошо. Может быть даже генеральный лишит квартальной и годовой премии сочинителя циркуляра за развал работы.

А в жизни бывает по разному. Очень по разному…

PS. Кстати. ISO 9001 направлена на размывание границ обязанностей смежных отделов. Создатели стандарта полагали, что их творение направлено не на создание циркуляров и жесткое следование им. Но, напротив, на увеличение кросфункциональности, сокращению верткальных связей и решение вопросов между отделами на уровне инженеров, без привлечения менеджеров.

По мотивам: http://www.yatester.ru/2009/09/5-sposobov-otvetit-na-nechestnue.html. Получилось немного злее, чем хотелось. А потому дисклаймер: “Диалоги вымышлены и конкретно к вашей фирме, дорогой читатель, это никак не относится.”

* Почему именно тестирование является «узким местом» проекта?
Это вопрос к топ менеджерам. Это именно их вина, что наиболее дешевый участок стал бутылочным горлышком. За подробностями управления производством в сфере подверженной девиациям обратитесь к книгам Голдрата “Цель” и “Критическая цепь”

* Почему у нас столько ошибок?
Потому что:
1) мы не провели работу по предотвращению возникновения ошибок. Это вина ПМ-а.
2) Потому что квалификация и численный состав проектной команды не соответствуют масштабу проекта. А это вина опять таки топ менеджера.

* Что мы можем сделать, чтобы улучшить производительность отдела тестирования?
1) Улучшить документацию. К аналитикам.
2) улучшить такой показатель качества проекта как “Тестопригодность”. Смотри ГОСТ 9126 и сопутствующие документы. Это не к тестировщикам, это к постановщикам процессов (QA), архитекторам (от БД до GUI) и создателям стандартов (кодирования, проектирования GUI, проектирования БД и пр.)
3) Увеличить численность отдела тестирования и организовать наконец то курсы повышения квалификации для инженеров. К HR и топ менеджерам.

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

Правильный ответ: “Какого черта вы задаете эти вопросы лидеру группы тестирования?” Он то здесь причем?

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

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

Отчет, видео: http://team.custis.ru/2009/08/blog-post_06.html.

Мои искренние поздравления Стасу.

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

---

Жила была команда программистов. Для простоты предположим, что они не выполняли никаких работ связанных с аналитикой, архитектурой, GUI и написанием технической документацией, т.к. писали они расчетные модули и всю аналитику и описание API им спускали сверху. И было их 8 человек. Нормальная такая agile команда.Надо сказать, что модуль расчета квартплаты или трафика сотового оператора - вещь сложная и закодировать это дело без ошибок удается редко. Я бы даже сказал, исчезающе редко. Соответственно, тестированием тоже приходилось заниматься. И тратилось на тестирование половина времени программистов. Иногда больше, иногда меньше. Естественно, что такое положение дел никого не устраивало.Но узнало начальство, что в деле тестирования тестировщики более производительны, нежели кодировщики.  Для простоты будем считать, что в два раза [1]. Другими словами - один тестировщик в деле тестирования двух программистов накормит. Прошу прощения, заменит.
И вот настал замечательный день. В коллектив влился тестировщик. Начальство обнародавало приказ, что с текущего дня каждый занимается своим делом. Кодировщики, пардон, программисты - кодируют, а тестировщики - тестируют. Программисты вздохнули с облегчением и пошли заниматься любимым делом. И зажили они в ладу и свокойствии.

А что стало с общим выхлопом отдела? Ведь не просто так все затевалось.

Элементарный расчет показывает, что совокупный выхлоп отдела упал в два раза.Вдумайтесь в это. Был принят еще один человек, т.е. увеличены расходы, и … И производительность отдела сократилась вдвое. Опана.

Такое уменьшение неспособен вызвать ни один “активно невовлеченный”. Да и для профессионального  диверсанта такой результат является едва ли не мечтой. Но ведь не было, не было диверсанта! И люди все были хорошие. По настоящему радеющие за успех.

А объяснение простое. Некомпетентность руководства (незнание основ управления производством) привело к тому, что сочетание факторов:

• Положение “каждый занимается своим делом”
• Несоответствие между  соотношениям трудоемкостей операций и обеспечением сотрудниками

привело к катастрофе. Скажете так не бывает? Еще как бывает. Встречается сплошь и рядом [2].

Что можно сделать в данной ситуации. Про курсы повышение квалификации или замену руководство все понятно. А что хороший руководитель должен сделать?

Вариантов решения несколько.

1. Сохранить кроссфункциональность. Т.е. программисты все равно будут не только кодировать, но и тестировать тоже. Иными словами это ликвидация парадигмы: “Для достижения максимальной эффективности каждого сотрудника, каждый сотрудник занимается только своим делом”.
2. Нанять  еще тестировщиков. Кстати, вопрос к знатокам. Сколько должно быть тестировщиков с учетом рисков заболевания/увольнения и девиаций трудоемкостей от проекта к проекту?

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

---

[1] Мои наблюдения показывают, что скорее в 3-5 раз.

[2] Падение выхлопа из-за безграмотного управления всего в два раза - это еще отличный результат. Даже падение в 10 раз не редкость.