Уверен, многим из вас знакомы ситуации, когда вам приходится сотворить что-то, что при нормальных обстоятельствах занимает неделю, за одну ночь. Предлагаю обсудить, почему мы попадаем в такие ситуации и как из них выпутываться, не ударив в грязь лицом и не доведя себя до нервного срыва.
Под катом – история из жизни команды разработчиков от руководителя отдела сопровождения бизнес-систем «Инфосистемы Джет», Романа Грибкова.
Обычно подготовка к акции занимает несколько дней, – в идеале – неделю, чтобы ничего не упало/случилось/произошло/внезапнулось, и случайно закравшиеся ошибки не разорили заказчика. Обычно мы готовим механику акции и проверяем ее в тестовом режиме, чтобы точно знать, что все будет работать как надо. Но в этот раз все случилось совсем по-другому.
Однажды в пятницу около 16.00, когда все предвкушали свободный от работы вечер, были готовы выключить компы и покинуть рабочие места, на нас вдруг упал представитель заказчика со срочной акцией.
«Нам очень срочно надо, проверять не будем, делайте сразу на продуктиве!»
Оказывается, мы должны запустить новую акцию (новую, на проде, Карл!) вечером в пятницу! И не в следующую пятницу, как мы было подумали сразу, а в ту, которая уже близилась к счастливому для большинства трудящихся завершению.
Окей, вечер пятницы перестал быть томным, что же тут надо делать? Ничего нового делать не надо, всего-навсего начать с начала и дойти до конца, но не за неделю, а за несколько часов, пффф…>_< .
Хороший вопрос. Тем более, что на этапе заключения договора мы прописываем в регламенте, сколько времени на что требуется. В этом конкретном случае была заложена неделя на подготовку механики маркетинговой акции, и мы не были обязаны «пилить» ее за пятничный вечер. Но, мы всегда стараемся идти навстречу клиенту, если «очень надо». При этом объясняем риски, которые могут идти «пакетом» с рекордными сроками.
Расчехлили чек-лист подготовки акции (признак того, что мы хорошо знаем, что и как делать) и собрали конференцию с заказчиком в скайпе (если знаем кого собрать, значит понятен процесс и есть ресурсы).
Небольшое лирическое отступление: сложно было в конференции удержаться от смеха над никами и аватарами друг друга, тогда еще не было поголовной удаленки, и всех собрали через личные аккаунты, соответственно, некоторый зашли, например, под никами жён/мужей/детей.
На конференции прошли каждый шаг и срезали все, что можно срезать, пояснив риски, которые появляются при таком сокращении пути. После этого обсудили механику акции и сформулировали ее параметры. На этой же конференции получили все необходимы согласования.
После создали общий чат, где проходило постоянное информирование всех заинтересованных лиц о ходе работ, там же обсуждали нюансы реализации и быстро согласовывали изменения при необходимости.
В итоге, к началу открытия магазинов на Дальнем Востоке у нас все было готово, осталось только проверить в боевых условиях и разойтись спать.
Все работало как по маслу, и даже «костыли» не понадобились, хотя мы ждали подвоха, ведь когда «пилишь» что-то на скорую руку, всякое может случиться, например, простая «очепятка», которую все проглядели.
Вспоминая эту историю, я размышлял над вопросами, как мы это сделали, почему все получилось быстро и качественно (мы же знаем, что так не бывает). В поддержке обычно приходится выяснять, почему все пошло кувырком и как не допустить этого в будущем, а тут – наоборот.
Обычно, когда прилетают срочные задачи, я взвешиваю их по условиям, описанным ранее и сразу обозначаю риски:
Конечно, мы всегда пытаемся сделать так, чтобы решение всех устраивало, и даже в невозможных на первый взгляд ситуациях находим способ, как выручить заказчика.
Бывают не только технические аварии (инфра и приклад), но и «бизнес-аварии». Описанная выше ситуация, – это хороший пример, когда дискоммуникация партнеров нашего заказчика привела к авралу. Во избежание таких бизнес-аварий хочется дать маркетологам подробный чек-лист для подготовки акций, но это уже совсем другая тема.
З.Ы. Я точно знаю, что для маркетологов приготовлены отдельные котлы в аду, но следует с ними дружить, почаще звонить и писать, дабы знать их коварные планы, а самое главное, вовремя узнавать об их «гениальных» идеях, которые нам приходится претворять в жизнь.
habr.com
Под катом – история из жизни команды разработчиков от руководителя отдела сопровождения бизнес-систем «Инфосистемы Джет», Романа Грибкова.
Пятничная «Ахтунг» акция
Случилось это в то время, когда мы с командой работали на одного ритейлера. Мы автоматизировали программу лояльности и маркетинговые акции для сети, включающей сотни торговых точек по всей стране в девяти часовых поясах.Обычно подготовка к акции занимает несколько дней, – в идеале – неделю, чтобы ничего не упало/случилось/произошло/внезапнулось, и случайно закравшиеся ошибки не разорили заказчика. Обычно мы готовим механику акции и проверяем ее в тестовом режиме, чтобы точно знать, что все будет работать как надо. Но в этот раз все случилось совсем по-другому.
Однажды в пятницу около 16.00, когда все предвкушали свободный от работы вечер, были готовы выключить компы и покинуть рабочие места, на нас вдруг упал представитель заказчика со срочной акцией.
«Нам очень срочно надо, проверять не будем, делайте сразу на продуктиве!»
Оказывается, мы должны запустить новую акцию (новую, на проде, Карл!) вечером в пятницу! И не в следующую пятницу, как мы было подумали сразу, а в ту, которая уже близилась к счастливому для большинства трудящихся завершению.
Окей, вечер пятницы перестал быть томным, что же тут надо делать? Ничего нового делать не надо, всего-навсего начать с начала и дойти до конца, но не за неделю, а за несколько часов, пффф…>_< .
Почему б не отказаться?
Хороший вопрос. Тем более, что на этапе заключения договора мы прописываем в регламенте, сколько времени на что требуется. В этом конкретном случае была заложена неделя на подготовку механики маркетинговой акции, и мы не были обязаны «пилить» ее за пятничный вечер. Но, мы всегда стараемся идти навстречу клиенту, если «очень надо». При этом объясняем риски, которые могут идти «пакетом» с рекордными сроками.
Когда можно браться за «горящую» задачу?
По опыту знаю, что можно попытаться сделать задачу в супер-сжатые сроки, если:- Задача хорошо знакома и понятна с технической стороны исполнителю и заказчику;
- Процессы, связанные с ней, отлажены и находятся в рабочем состоянии;
- Все human-ресурсы для выполнения доступны здесь и сейчас, и они уже делали такое недавно.
Расчехлили чек-лист подготовки акции (признак того, что мы хорошо знаем, что и как делать) и собрали конференцию с заказчиком в скайпе (если знаем кого собрать, значит понятен процесс и есть ресурсы).
Небольшое лирическое отступление: сложно было в конференции удержаться от смеха над никами и аватарами друг друга, тогда еще не было поголовной удаленки, и всех собрали через личные аккаунты, соответственно, некоторый зашли, например, под никами жён/мужей/детей.
На конференции прошли каждый шаг и срезали все, что можно срезать, пояснив риски, которые появляются при таком сокращении пути. После этого обсудили механику акции и сформулировали ее параметры. На этой же конференции получили все необходимы согласования.
После создали общий чат, где проходило постоянное информирование всех заинтересованных лиц о ходе работ, там же обсуждали нюансы реализации и быстро согласовывали изменения при необходимости.
В итоге, к началу открытия магазинов на Дальнем Востоке у нас все было готово, осталось только проверить в боевых условиях и разойтись спать.
Все работало как по маслу, и даже «костыли» не понадобились, хотя мы ждали подвоха, ведь когда «пилишь» что-то на скорую руку, всякое может случиться, например, простая «очепятка», которую все проглядели.
Вспоминая эту историю, я размышлял над вопросами, как мы это сделали, почему все получилось быстро и качественно (мы же знаем, что так не бывает). В поддержке обычно приходится выяснять, почему все пошло кувырком и как не допустить этого в будущем, а тут – наоборот.
Когда лучше НЕ браться за «горящую» задачу?
Обычно, когда прилетают срочные задачи, я взвешиваю их по условиям, описанным ранее и сразу обозначаю риски:
- Если задача не знакома – даже если она кажется легкой, это точно будет небыстро и с косяками. Не ошибается только тот, кто ничего не делает, или делает то, что сделал уже много раз и недавно. Но люди склонны смотреть на чужой труд, как на несложный, поэтому «да это фигня, справишься за полчаса» может растянуться на неделю.
- Окей, задача знакома, но мы это делаем редко и всегда ищем правильный путь в процессах, поэтому «вчера» скорее всего не получится.
- Если в команде нет людей, кто уже делал эту задачу, понадобится больше времени, чтобы сделать ее качественно.
Конечно, мы всегда пытаемся сделать так, чтобы решение всех устраивало, и даже в невозможных на первый взгляд ситуациях находим способ, как выручить заказчика.
Бывают не только технические аварии (инфра и приклад), но и «бизнес-аварии». Описанная выше ситуация, – это хороший пример, когда дискоммуникация партнеров нашего заказчика привела к авралу. Во избежание таких бизнес-аварий хочется дать маркетологам подробный чек-лист для подготовки акций, но это уже совсем другая тема.
З.Ы. Я точно знаю, что для маркетологов приготовлены отдельные котлы в аду, но следует с ними дружить, почаще звонить и писать, дабы знать их коварные планы, а самое главное, вовремя узнавать об их «гениальных» идеях, которые нам приходится претворять в жизнь.
Драма из жизни разработчиков. Стоит ли браться за «времени нет, делайте сразу на проде»?
Уверен, многим из вас знакомы ситуации, когда вам приходится сотворить что-то, что при нормальных обстоятельствах занимает неделю, за одну ночь. Предлагаю обсудить, почему мы попадаем в такие ситуации...
habr.com