?

Log in

No account? Create an account

psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Упражнение для менеджера: пятничные тесты
psilonsk


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

Сейчас вечер пятницы. Вы вдруг решаете протестировать ваш продукт, берете чашечку чая, открываете ноутбук и начинаете работу с сервисом.

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

В вашей компании существует отдел, ответственный за разработку этого сервиса.

Каковы ваши действия как руководителя в этой ситуации?  




promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

Сходить к QA и попросить завести багу.

Почему самому не завести?

ну чья ошибка - пусть и исправляют, причем с выходом в выходные.
лишение ништяков - если это не тестовый продукт.
увольнение - если не первый случай.

По телефону узнать у человека, ответственного за сей проект, кратко текущий статус. Закончена ли работа над проектом, или он еще тестируется, дорабатывается. А дальше - в зависимости от ситуации.

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

Если же работа еще не завершена, идет тестирование (может быть, на небольшой аудитории реальных клиентов), то все вопросы оставлю до понедельника.

Ок, принято. )

(Deleted comment)
В описанной ситуации не 1 кодер. Ну, так, на всякий случай. )

Напишу в отдел кому там у них есть, PO или QA. Пусть фиксят в соответствии с процессами. По описанию, так майнор баг, но раз в продкшене, то хай прайорити. Уж на выходных точно не обязательно фиксить, не в больнице ж хиругам поиск этот нужен. Попрошу еще, чтоб разобрались, где недотестировали или недоанализировали, чтоб на будущее иправиться.
А что, в России можно уволить за баг? А кого уволить, девелопера, тестера или менеджера? А если уволить, то надо ж нового брать, обучать, вводить в курс дела, одни растраты, разве майнор баг этого стоит?

Ок, принято. )

Про увольнение я не говорил...

(Deleted comment)
Скорее, второе - сервисом пользуется много народу.

Мысленно собрал бы всю команду из пивных и клубов и заставил бы все выходные исправлять и тестировать, тестировать и исправлять, фоном бы поставил фашистов с автоматами, и к вечеру воскресенья приказал бы расстрелять всех, но так чтобы к понедельнику оправились.

В реальности же, собрал бы команду в понедельник, и сказал бы что нас постигла честь и к примеру Тим Кук (Папа Римский/Путин/Обама) искал автомобиль в нашем сервисе, затем на пике ложной гордости поставил бы игрушечный автомобиль на стол, и сказал бы, что вот что он нашёл. Пауза, ну а дальше по первому сценарию :)

Хорошо сказано. ))

- Новые релизы должны быть не в пятницу.
- QA должен все тестировать до релиза.
- Винить разработчиков в багах неправильно, они бывают, должен был QA выловить.
- Поэтому просить разработчиков выходить на выходных неправильно (в каких-то случаях просить можно, но заранее и не в данном случае). Исправят в понедельник.
- К разработчикам меры применяться вряд ли будут.
- К QA, в случае достаточно заметного бага, меры применяться будут.

P.S. Чай в пятницу вечером? Хм... "Поступали сигналы – не чай он там пьет!" (с)


Edited at 2015-07-29 12:43 pm (UTC)

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

Ну и еще, номинально, бывает, что тестеров нет - есть проекты, в которых их исключают, а баги берут прямо из продакшена. Долго объяснять почему, но бывает, что оно оправдывается.

а так, плюс один.

В общем порядка написать в support.

Что значит "в общем порядке"?

закрою ноутбук и пойду книжку почитаю или кино хорошее посмотрю, оставив себе ремайндер на понедельник. в понедельник перепроверю, запишу кейс, по привычке читать документацию, вероятно, запрошу когдатошнее ТЗ и change log, и буду думать, как именно эскалировать - это сильно зависит и от статуса проекта (и проект ли это вообще, или он закрыт давно), и от структуры maintenance. В любом случае, позову руководителя отдела разработки второй головой.

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

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

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


А можно вопрос - я помню, вы в промальпе активно трудитесь, это совет из промальповского мира? Или атишный (или какой-то еще) опыт тоже учитывается?

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

А если по теме, то
1. Звоню руководителю соответствующего отдела, прошу временно заблокировать сервис для клиентов, потому что лучше Извините-временно-недоступный-сервис, чем косячный
2. Сообщаю, что в понедельник утром ожидаю от него план починки сервиса со сроками + анализ того, почему сырой продукт оказался на рынке и как этого не допустить в будущем

Зачем спрашивать план починки сервиса? Почему нельзя просто починить?

Накатаю тикет в баг-трекер, подпишусь на наблюдение статуса исправления.

Отличный жизненный вопрос.

В любом случае надо зафиксировать ошибку. Возможно, скриншота хватит. Если есть техподдержка, работающая в это время, лучше туда позвонить и убедиться что они осознают проблему.

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

Далее начинается основная клоунада.

Если подобные ошибки - редкий случай, да и критичность невысока - то можно отложить до понедельника. Или это 1 января и все пьяны.

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

А "животворящих пендюлей" отвалить в любом случае надо.

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

А владелец сам ебётся со своим любимым сервисом, неадекватной половиной и поиском новых по трёхкратному тарифу.

Смотря насколько критично.
Т.е. если сервис работает 7 дней в неделю - то подрываем ответственных для ускоренного исправления.
Если только в будние дни, то все равно подрываем, но в меньшей степени, чтобы спокойно исправили до понедельника.