avatarakali (avatarakali) wrote,
avatarakali
avatarakali

Category:

Рабочее: про проблемы в срочных проектах

Выпала из виртуальности на несколько дней - не постила, не листала, не читала, не просматривала, не кликала, не коментила.

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


Есть у нас такой документ, в котором мы после каждой версии пишем, кто что думает по поводу того, как все прошло, что получилось, что не очень, какие выводы, и какие действия предписываются впредь. Называется Lessons Learned. Обычно по результатом из пунктов, ну, может 20ти, пара пунктов действительно помогает, предворяется в жизнь, что-то улучшается, а про остальное все благополучно забывают со временем, если не установился официальный процесс по результатам какого-то предложения. Ну и будда с ними, казалось бы.

Но! Как показала реальность, мы только что наступили на очень даже многие грабли, на которые зареклись не наступать в прошлых LL!


Причина 1) Мы все такие секретные-секретные когда дело касается новой функциональности. Настолько секретные, что секретная функциональность обычно передается под рассписку о неразглашении под страхом смертной казни. Что, как бы не вопрос. Вопрос в том, что информацию до людей доводят on a need to know basis. Что практически означает "завтра начинаем".

Когда секретный проект был в прошлый раз, где-то в Lessons Learned было написано, что не надо больше так затягивать с раздачей информации. Но кто о них помнит?

Проблема 1.2 В планировании для работы с такими функциональностями реальные люди не учитываются, учитываются пунктики типа "работник 1, 2, 3", без присутствия этих работников еще в проекте. Правильно - откуда им заранее взяться? Их же не планировали.

Результат: в последний момент "с улицы" набирается человек 100. Ок, не 100, но так 5-6 человек на каждую единицу опытных работников.
Результат: вместо 7ми человек (1 опытный + 6 "с улицы") работа реально делается в 2-3 раза медленне запланированного темпа, где-то как если бы 2-3 человека работали. Почему? Потому, что опытного постоянно отвлекают вопросами, а неопытные вообще ничего не могут сделать самостоятельно. Что логично - ведь у них не было обучения, их сразу кинули в бой!

В прошлый раз, когда мы столкнулись с проблемой работы с новичками (я об этом уже писала как раз по тегу work), я стонала, конечно, что их обучать сложно, но ччччерт, у меня тогда хотя бы было время их обучить хоть до какого-то уровня!
В этот же раз люди из разных офисов нашей глобальной компании по всему земному шару втыкались в проект на ходу!
Результат я описала выше.


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

Проблема 1.3 Так как все так супер-секретно и в последний момент, что, оказывается, сюрпрайз-сюрпрайз, люди, которые начинают работать с функциональностью, сразу замечают, какие коррективы нужно внести, то есть функциональность меняется КАЖДЫЙ ДЕНЬ. Каждый день в течение всего проекта меняется документация и дается новый код. Нет, дорогие мои, вы где-нибудь это видели, чтобы каждый день весь код с ног на голову ставился? Это не проходит ни по каким правилам ведения проектов. Но у меня серьезное подозрение в том, что наши менеджеры обо всех этих глупостях типа академических знаний проджект менеджмента не задумываются, поэтому соглашаются на все эти изменения.

Причина 2) Допустим в конце концов тестирование таки началось, не смотря на то, что все постоянно меняется, как во Дворе Хаоса (с) Роджер Желязны.
Перед началом тестирования есть такой пункт "Готовность системы к тестированию". В котором четко записывается, что нам надо, чтобы начать тестировать, и какие тесты программеры уже закончили.

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

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

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

Вечная проблема, ВЕЧНАЯ, повторяется из версии в версию: кастомер не считает наше тестирование существующим в принципе и у него по временным рамкам выдача данных для новой функциональности всегда стоит для тестирования ровно перед выдачей версии, для последнего, то есть, этапа тестирования. Когда поезд уже ушел. И каждый раз нам приходится просить и умолять выдать нам данные заранее, и каждый раз это делается в виде боооольшого одолжения со стороны заказчика. Я понимаю, что тут вопрос координации менеджеров проектов с нашей стороны и со стороны заказчика. Но это понимание не отменяет того факта, что начинаем мы тестирование всегда на левых, руками сляпаных данных (красивым словом "синтетические данные", кстати, называется), а потом заказчик выполняет цыганочку с выходом и выдает реальные данные тогда, когда мы уже практически все свое тестирование закончили. И получается сюрпраааайз!!! - там еще, оказывается поле непахано, на новых данных тестирование надо переделывать сначала! Доделывается все в последний момент.

Проблема 2.2. Точно так же, как и с данными для тестирования, обстоит ситуация с интерфейсами с системами заказчика.
То есть вот тестируем мы свою систему. Но мы же не в вакууме ее тестируем. Она же в реальности с другими системами работает.
Для правильных результатов проверки функциональности для тестирования необходима связь с другими интерфейсами в компании.

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

Результат: как и с данными. Каждый день нашего тестирования мы умоляем заказчика сделать интерфейсы, нам в качетстве боооольшого одолжения, это делается, но все равно не так потому, что да-да-да, заказчик реально не может подготовить системы заранее потому, что это совершенно не входило в его планы! Результат - наши планы стоят, пока заказчик нервно пытается "на коленке" доделать интерфейсы.

А теперь, барабанная дробь! - результат всех этих пунктов одновременно: тестирование не укладывается по выполнению намеченного плана в заданные рамки. О чем пишется и звонится в колокол КАЖДЫЙ ДЕНЬ большими буквами.

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

В результате в неделю Х наши шефы берут наши команды и мы работаем по N часов в день (действительно, по много часов, в авральном режиме, а прошлой ночью я, как и коллеги мои, работала до 3х утра, а потом передали эстафету на "другие берега", а шеф мой вообще, кажется, не спал, координируя наши команды - то есть работа велась non-stop), заканчиваем все - но как!
Представляете, если в последние пару дней сделать то, что было распланировано на 2 недели ( на которые мы отстали по вышеперечисленным причинам). Это как в том мультфильме: могу и 7 шапок сшить.

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

Keeping my fingers crossed - надеюсь, что на качестве работы системы в целом это не отразится!

P.S. Поэтому я в этот раз напишу LL: см п. 1 (с) следовать LL №такой-то от предыдущих выпусков!
Tags: work
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 51 comments