Есть у меня пару человек, которые активно мне поставляют… нет не дурь (сами видно, заразы все выкуривают), но забавные корпоративные истории. Так, что выкладываю одну из них, буквально с минимальной обработкой. Все повествование ведется от лица поставщика (местами даже диллера 🙂
__________
В общем, преамбула совмещается с фабулой и будет многа букаф. Это скорее просто жалобы на тяжелую жизнь, но возможно тебе это знакомо. Короче говоря, у меня нас есть несколько тимов, каждый из которых пишет свой продукт и OEM тим, которые все эти продукты собирает, кастомизируют и раздают оем клиентам. Рулит этим тимом Configuration manager.
На прошлой неделе наш Configuration manager поднял плач Ярославны «как у нас все хуево с качеством, всем пиздец». Ну ок. В целом, я с ним согласен, но почему так получилось — вопрос интересный. Получилось так, что по целому ряду стратегических решений топ менеджмента, принятых год-полтора назад, стандартный подход — нахуй качество, надо рынок завоевывать, а остальное потом исправим. Ну, рынок завоевали, тока теперь на поддержание этой кучи говна в жизнеспособном состоянии тратятся огромные ресурсы, кастомизации под каждого клиента приходится приделывать болтами и сварочным аппаратом где-то сбоку.
Так вот, прошлонедельный плач был по поводу того, что тестеры из оем находят много багов, относящихся к самому продукту. И мы мол не знаем, что именно получает команда оем от команд продуктовых. Наш Configuration менеджер поднял дискуссию на высоком уровне и в итоге наш VP engineering’а произнес сакраментальную фразу: «А давайте померяем качество!»
Ну давайте. Встречный вопрос — а как мы будем мерять качество? Он грит, а хуй его знает. Вот пойдите, мои верные слуги, простите, менеджеры, и придумайте, как мы будем мерять качество. Мол, похоже QA хуево работают, но хер его знает. Мне изначально было все это похую, потому как я за qa не отвечаю и вообще это проблемы project manager’а.
В общем, как тут принято начинать работу над любым вопросом (хоть формы зеркала в сортире)? Правильно — соберем митинг. Пригласим всех ну или не всех. В общем, собрались мы митинговать — я, мой начальник, Configuration менеджер, директор инжениринг и прочая братия.
Project manager говорит — тебе нужно сказать, что ты как product manager хочешь сделать для измерения качества? Я говорю, охуенные заявочки. А ниче, шо инжениринг — это вы, а не я? Я вам как product manager могу тока сказать, что качество наверное хуевое, а как его мерять — это уже ваши дела. Померяйте и принесите. Они грят -а мы не знаем, как мерять качество. Вот если нам скажут, как мерять, мы померяем, и отчитаемся о проделанной работе.
Тут вступает Ленский, в смысле Configuration менеджер. Мне, сообщает, все равно, как и кто будет мерять, но мне надо, чтобы когда моему тиму сдают в релиз продукт, сообщали, какое у него качество. и так, чтобы было четко и понятно. а еще лучше говорит, чтобы ты сам там со своими пацанами разбирался, задерживал релизы, а мне приносили тока когда все готово.
Мой начальник, понимая, что эта хуйня и его касается, воспользовался авторитетом и послал их нахуй тут же с таким предложением. Мол, наша задача вообще ставить задачи и acceptance criteria. а то что вы там в своем инжениринга собрались мерять — это вы там сами разбирайтесь.
Короче этот волейбол продолжался два рабочих дня. В промежутках между этими безумно продуктивными дебатами я (хаха, наивный мальчег) ходил по людям и пытался найти, кто вообще обладает подобными знаниями и отвечает за эти вещи. пошел сначала к инженирингу. они замахали руками, зажмурились и закричали «не, мы сами нихуя не знаем». ну ладно, пошел к QA. QA менеджерша перепуганным голосом сказала, что она сделает все, что ей скажут, особенно если расскажут, как делать.
Мне все это надоело, я пошел к моему боссу и говорю — вот такая хуйня. Я в жизни никогда qa не был, какие у них там метрики, методы и тд я понятия не имею. Он говорит, ладно, ну их всех нахуй. Раз никто нихера не знает, будем сами с тобой придумывать. Собрали очередной митинг. Вызвали все тех же танцоров.
Началось все уже привычно: А как нам померять качество? Я грю, ну самое простое, что приходит в голову — отсортировать тест кейсы по группам и собрать статистику по pass & fail. Все радостно закивали головами. Но тут вступил мой босс. Не, говорит, это все хорошо, но не люблю я эти тест кейс статистики. Вот когда я пишу acceptance criteria, я знаю, что это я написал и знаю, сколько они покрывают. а кто там писал ваши тест кейсы я не знаю, и как они написаны я тоже не знаю. Может они там покрывают 20% возможных use cases (надо заметить, у него есть основания так говорить). Давайте, говорит, лучше определим 10-20 основных функциональных областей (типа как epics), отдадим каждому члену команды на тестинг и послушаем выводы.
Тут вступает project manager: не, если программистов послушать, так у них все работает идеально, а если не работает, то это исключение и дурацкий юз кейс (что впрочем, тоже логично).
Я говорю, а может мы не будем изобретать велосипед? Судя по всему,никто из нас не знает, что значит померять качество. Но вполне возможно, есть какие-то работы на эту тему, подходы, тулзы. Я даже готов почитать это все, чтобы с умным видом всех вас просветить позже. даже если нихуя там нету, что тоже может быть. Но естественно это не могло пройти, потому как Configuration менеджер тут же застонал, что у него сейчас релиз, а как мы вообще можем релизить, не зная качество, так что померять надо прямо сейчас и срочно.
Я говорю, а как мы до этого релизили? На что следует ответ: ну так это же было неправильно! Мы же растем, мы должны знать, что мы релизим. Ок, отвечаю я, а как на счет того, чтобы мы сейчас неправильно отрелизили по старинке, не страдали хуйней, а по ходу следующих несколько недель я почитаю, подумаю, да и вообще что-то придумаем. Он на меня посмотрел так, как будто я лично признался в массовых убийствах христианских младенцев и сообщил: ТЫ ЧТО, ХОЧЕШЬ РЕЛИЗИТЬ, НЕ ЗНАЯ, ЧТО ТЫ РЕЛИЗИШЬ??? И ЭТО НЕ СГНАЛ ТРЕВОГИ ДЛЯ ТЕБЯ???
Бля, чувак, да у нас под тысчу открытых багов. Я знаю, что мы релизим полное гавно и мы его не разгребем сейчас. И скорее всего никогда не разгребем, потому как у нас одни обязательства. Да, отвечает он,- но мы хотя бы сможем померять и будем знать, что и как в общем, громко поплевавшись мы решили совместить наши гениальные идеи. Решили, что я напишу список критичных функциональных областей, отправлю тимам, инженеры с их менеджерами решат, что и как делать, а дальше по каждой из этих областей мы соберем и проценты по тест кейсам и общие наблюдения. Из-за этого релиз был торжественно отложен. Как же релизиться, если не померяли?
И теперь финишная прямая
Я написал письмо, отправил тимам с их инженерным менеджментом, а он — менеджмент тот — пришел ко мне и сказал: а мы че-то не поняли, в каком виде вы это хотите получить? @#$@#$@#$…. В виде процента по тест кейсам бля и личным соображениям бля. Хотя я думал, вы там что-то с QA придумаете. Ответ последовал ожидаемый: так а шо QA, они качество мерять не умеют. Как скажете, так и померяем.
Я устало махнул рукой, и сказал — ну вот пусть и меряют по своим тест кейсам.
еще не знаю как на это отреагирует публика, но пост «за;%ись» )
вспоминаю свои деньки, когда также маялся с качеством )
А не спам ли это часом, уж очень подозрительный URL?
нет, не спам, все ок )
Вот и ладненько 😉
Митинги это наше все 🙂
Кстати, может им нужен мужик с яйцами, который все поставит и настроит жесткой рукой. Демократия это зло в данном случае.
Я конечно передам 😉
Но, боюсь, что дело не в наличии яиц.
Кстати, насчет демократии — это больная тема. Я вот тут писал:
http://victorronin.com/2008/12/09/odna-golova-xorosho-luchshe-li-dve/
Зачастую, решение и ответственность лежащие на одном человеке, лучше чем размазывание решений и ответственности по всем.
Но фразу «Демократия — это зло (в данном случае)» произносить в всех западных странах можно только шопотом под простыней, зубами к стенке.
Насколько я понимаю корпоративную кухню, вся наука в том чтобы прикрыть задницу. Если отфильтровать эмоции и действия, картинка получается логичной. Configuration manager видит что продукт полное говно и как только он его выкатит, его сожрут. На своем уровне он, естественно, ничего исправить уже не может, поэтому он пытается передожить ответственность на engineering people. Ему на самом деле не нужно «мерить качество». Любой студент знает, что качество это некалиброванная динамическая характеристика и однократное его измерение по любой методике ничего не даст. Типа configuration manager этого не знает, ага. На самом деле ему не нужно мерить качество, ему нужно чтобы программисты сказали «все заебись». И QA сказало «все заебись». Чтобы когда разьяренные топы прибегут его рвать, он мог показать пальчиком на программистов и QA. Дескать, они сказали, а я не проверил. Да и ресурсов нет у меня за всеми проверять. Понятно что программисты такого говорить не хотят. И QA не хочет. А аналитики так просто сразу на йух посылают. Вот и весь хрен, до сантима.
Что же, качество мерить нельзя? Можно конечно. У любого PMа есть под рукой багтрекер и VCS. Посчитать из этого стандартные метрики вроде багов на строчку кода; второй производной от багов на строчку кода; процент переоткрытий багов; процент багов, найденных кастомерами; времени жизни бага, времени жизни запроса на кастомизацию и т.п. Сами по себе эти данные бесполезны, зато если смотреть их в динамике, состояние проекта видно как на ладони. Только никакой вменяемый PM эти данные не отдаст. Потому что речь не о том чтобы повысить качество, а о том чтобы найти козла. Вот и начинаются гнилые разговоры о том, что никто не знает как мерить, да о том, что QA мух не ловит. На кой вообще нужен QA если он не проверяет acceptence критерии и не дает аналитикам на review.
Ваш комментарий дал больше поводов для размышлений чем сам пост.
Какие периоды стоит брать за точку отчета, для анализа динамики проекта? Неделю? Итерацию? Релиз?
p.s. Не спамер, потому что нет сайта 🙂
Однозначно не спамер 😉 Больше одной — двух строк они не пишут 🙂
Согласен на 150%. Очень точно и правильно все описано.
Действительно — это прикрытие своей задницы и перевода стрелок. И в больших компаниях, даже можно понять почему это происходит. Чаще всего действительно ресурсов очень ограниченное количество и они размазаны. Поэтому ни у одного игрока нет возможность взять на себя ответственность и сделать что-то гораздо лучше (кстати, еще вопрос, насколько погладят за это по голове). Поэтому все скорее играют в «защитные» стратегии.
Единственое, я не согласен с вот этим:
> Любой студент знает, что качество это некалиброванная динамическая характеристика и >однократное его измерение по любой методике ничего не даст.
а) Не любой студент
б) Не любой профессионал
>Посчитать из этого стандартные метрики вроде багов на строчку кода; второй производной от >багов на строчку кода; процент переоткрытий багов; процент багов, найденных >кастомерами; времени жизни бага, времени жизни запроса на кастомизацию и т.п.
Замечу, что если в компании ничего не меняется, то количество багов на строчку кода постепенно будет рости, вторая производная сложно сказать чему будет равна (но мне кажется некой константе), процент багов найденных заказчиками тоже будет примерно одним и тем же, время бага будет рости но медленно, кастомизация будет рости достаточно быстро.
Эта ситуация достаточно стандартная и тут и без измерений все понятно. Хотя, я безусловно согласен, что измерять надо, чтобы видить динамику.
Вопрос состоит, как и кому в такой политической ситуацие дейстовать, чтобы изменить эту ситуацию.
Есть еще одна проблема. Для средних и больших компаний, количество багов и количество строк величины большие, а вот размер команды работающей над продуктом зачастую величина не такая большая. Поэтому серьезные изменения в данных происходят на протяжении лет (что усложняет оценку проводимых мер).
>а) Не любой студент
Ладно, не любой а только тот, который доучился до четвертого курса и не забивал на
лекции. Потому что в курсе «Управление разработкой» о метриках рассказывают.
>б) Не любой профессионал
Да ладно. Всякий профессиональный менеджер в корпорации читал PMBOK, это у них культовая книга, как библия у христиан. Там целая глава посвящена тому что такое качество и как им управлять. Про именно софтверные метрики, там, правда нет, но об этом можно спросить студента из предыдущего пункта.
>Замечу, что если в компании ничего не меняется,
Я, честно говоря, не знаю что означает _ничего не меняется_? Совсем кода не пишут и багов не исправляют? Тогда и мерить нечего. Если все же что-то делают, то как будут меняться метрики еще погадать надо. Среднее время на закрытие бага может как расти (кода-то больше становится) так и уменьшаться (программисты начинают лучше ориентироваться в коде). Тут куча эффектов может сработать, так что без измерений это все гадания на кофейной гуще. Менеджеру, конечно, и без метрик видно что происходит, только не каждому и чаще всего с значительным опозданием, когда проект окончательно увяз в болоте.
>Вопрос состоит, как и кому в такой политической ситуацие дейстовать, чтобы изменить эту ситуацию.
Действовать кому? Корпорации? Корпорация это голем, у нее нет единой персонализированной воли. Конкретным сотрудникам? Сидеть тихо и не высовываться. Если попытаешься что-то изменить, козлом назначат тебя. Инженерам можно тихой сапой выделить проблемные места и начать их рефакторить/реинженирить. Аналитикам можно заняться ревью тест-планов на предмет соответствия их аналитическим фантазиям. PMам можно начать-таки мониторить обстановку у себя в проектах. Главное тихо, чтобы козлом не назначили. Это путь снизу. Или наоборот, громко. Скинуть испуганную начальницу тестеров, залезть на ее место, обозваться QA менеджером, подгрести под себя широкие полномочия по обеспечению качества. Потому что обкспечиь качество только тестированием невозможно. Это путь сверху.
а) Видно вас неплохо учили. У нас о понятие ошибок почему-то не говорилось. А уж о том, чтобы иметь test plan, acceptance criteria, базу данных ошибок и метрики — и не упоминалось.
б) Скажу честно, вы боооольшой оптимист. » Всякий профессиональный менеджер в корпорации читал PMBOK,» Ха-ха, два раза. Ситуаций описанный в статье в каждой компании на 5 штук на квадратный час. Не наводит ли это на мысль, что там таки не знаю как мерять качество? Зачастую эти менеджеры выросли из программистов, тех кто писали документацию и т.п. Даже, если они читали PMBOK (в чем я сомневаюсь), то прочтенный 9 лет назад он уже давно выветрился из головы.
Под «ситуация не меняется» я имею в виду
а) Состав примерно стабилен (потихоньку обновляется).
б) Новых методик/tool’ов не вводят
в) Новых метод управления не вводят
То бишь, просто делают то, что делали вчера.
На последний вопрос с ответом согласен.
Либо тихо, потихонькую улучшая качество на своем фронте
Либо громко, пытаясь в революционном порядке повысить качество на большом фронте.
По поводу прикрытия задницы всякими отчетами, кейсами, статистиками — есть хорошее выражение — «Чем больше бумаги — тем чище жопа» ))
Витя, привет. Если мерять качество серьезно, то это достаточно трудоемкий процесс. Копать в сторону iso и ieee. Действительно ключевой момент в выборе метрик. Посмотри пару ссылок:
http://www.pmprofy.ru/content/rus/67/672-article.asp
и вторую
http://guap.ru/dept04/caf46/textbooks/std_pro/index1_4.htm (эту без фанатизма, только левый столбец), возможно что-то поможет так сказать в выборе метрик.
Извини, обе ссылки на русском 🙂
Пробежался гразами. Но в целом,сейчас я не сильно этим озабочен. Это где-то там впереди по плану, но пока есть более насущные задачи (в том месте где работаю).
Если честно что меня в всех этих ISO и IEEE бескопоит, что в них надо угрохать X тысяч часов, чтобы получить от них какую-то пользу.
Я больше стал приверженец «легких» методик. Которые можно постепенно ввести, которые дают какую-то (может не полную) отдачу с самого начала. И на которые можно тратить по 5 минут в день.
Не ну если всем на это хочется тратить 5 минут времени, то таки да это корпоративное гавно 🙂
Не согласен. Scrum поднимается легко. И после первичной настройки, где-то занимает 10 минут в день от команды, плюс 1 час в неделю.
А что вы имеете в виду под легкими методиками? Можно примеры?
Например SCRUM. Или build automation.
Они могут не требовать супер больших изменений, могут зачастую вводиться постепенно, когда введены не требуют больших ресурсов на поддержание.
Пробуем Cruise Control — автоматизация сборок, сбор статистики, ее динамика.
Ну и применяем Agile & TDD.
Статистика хитрая вещь.
Например, количество багов идет вверх. О чем это говорит?
Может просто больше QA кинули на тестирование и они нашли не найденные раньше дефекты
Может новый код начал содержать больше дефектов.
Может просто программа растет в размерах и на самом деле количество проблем на одну фичу — падает.
и т.п.