Друзья, добрый день!
Мы продолжаем серию публикаций «без купюр» о проектах, связанных с разработкой, часто с приставкой «веб». Сегодня поговорим о том, как наиболее правильно и быстро проводить оценки работ и планировать релизы программной системы. Скорее всего, начинающие менеджеры и энергичные и ищущие себя разработчики будут шокированы рекомендациями, но, поверьте — цель стоит одна и только одна: помочь и сделать из вас настоящего джедая, который и пользу компании приносит, и проекты двигает, да и людей развивает одновременно. Такого джедая, который искренне не заслуживает быть обнаруженным в виде мумии в темной серверной между стойками с веб-серверами и базами данных веб-проекта, летящего в будущее без душевно документированного кода, ТЗ — лишь на энергии чистого «ХЗ». Итак, поехали!
Важно, крайне важно, особенно ключевой проектной силе — разработчикам, отличным специалистам, ежедневно покачивающим скилы в современных IDE, понять, что отсутствие здравого смысла в оценке работы начинается еще прежде желания «зачать идею». Особенно часто это происходит в веб-разработке, где во время проведения тендера нужно взять и сделать вид, что политизированная проблема курицы и яйца имеет «строгое решение»:
Станет немного легче, если найти близкие аналогии странного вышеописанного перформанса в окружающей природе:
Понятно, что пока легче не стало, особенно если вспомнить, что в перформансе нередко участвуют «дипломированные психологи» с обеих сторон, умеющие выглядеть убедительно, решительно, говорящие «да, конечно, сделаем!» и не понимающие базовых принципов разработки программного обеспечения. А если вспомнить, что иногда «выглядящие уверенно» на обеих концах проекта пересекают линию фронта, братаются, объединяются вместе и начинают прямо искренне негодуя что-то требовать конкретное от инженеров, не предоставляя четких формализованных ответов на четко поставленные вопросы… — прямо хочется уехать в академический отпуск в Антарктиду и забыться, обняв пингвинов и холодноводных, но не менее красивых от этого, русалок :-)
Трезво и аналитически строго воспринимать вышеописанный перформанс инженерам довольно больно, до кровоточения из глаз, поэтому совершают несколько известных психологических шагов, приближающих конкретику и реальную работу:
А если говорить серьезно, то на данном этапе нужно очень четко всем членам проектной команды осознать:
Итого, в конце перформанса должен произойти уверенный толчок вперед в неизвестное будущее, причем в хорошем, бодром настроении и взаимном желании слушать и слышать друг друга.
К сожалению, иногда буквально сразу возникает понимание, что запускаемый проект… никому не нужен, подергается, замрет и будет выброшен в архив:
Отрадно, но частенько попадаются и правильные старты проектов, которые можно выделить по следующим признакам. Придерживайтесь этого списка и старайтесь попасть в такие команды всеми правдами и неправдами:
Но имейте в виду — встреча с подобным подготовленным клиентом будет означать для инженерной команды спуск с IT-небес обетованных, пот, труд и кровь. Из вас вытрясут все знания шаблонов проектирования, научат писать простой код сразу без ошибок и желание вместо скриптика на PHP из 20 строк сделать фабрику классов вы будете отбрасывать как бесовское искушение. С утра, налив кофе, вы с удивлением обнаружите, что клиент, после (после!) вашего отдела тестирования, нашел и зарегистрировал в багтрекере еще 30-40 багов и рекомендует вам (вам!) еще тщательнее писать юнит-тесты и поменять мозг тестировщикам… Но зато это хорошо прокачивает :-)
Буду говорить прямо. Разумные люди, в т.ч. инженеры, понимают, что оценить еще не придуманное, мягко говоря, нельзя… Можно только уверенно соврать. Но, как известно, формальная математическая логика работает не у всех, поэтому иногда, все же, вы будете встречать собеседников, утверждающих что 1 + 1 = 11, причем так убедительно, что на глазах даже слезы могут появиться.
Но выход — есть: аналогия. Не зря в современном Agile подходе именно аналогия используется как фундаментальный кирпичик оценки. Работающие примеры аналогий в веб-разработке:
Важно использовать подход с аналогией и к квалификации команды:
Как-то так. Да, вы можете возразить, а как же PMBoK, диаграмма Ганта, Velicity, карточки в Канбане, толстые книжечки по «Agile Estimation», ускорение команды, метрики, петрики?Скажу честно — не работает и проведу аналогию с «машинным обучением».
Вас будут 5 лет учить 50 видам математики в ВУЗе, потом еще полгода на дорогих курсах про DataScience и MachineLearning, а потом на практике вы внезапно узнаете, что… научного подхода в этой области нет, нужно перебирать все варианты гиперпараметров, только времени на это вам никто не даст (дни и месяцы) и остается божественный рандомный перебор и, самое важное, ИНТУИЦИЯ. И ничего не остается, как… возвращаться и начинать читать теорию на курсах. Так и с оценкой работы в программных проектах — теории много, а работают на практике лишь крупицы знаний, замешанные на глубокой интуиции и, что одно и то же, опыте.
Чтобы действительно научиться оценивать трудоемкость программирования, нужно уехать из городов, пожить с аборигенами, поесть сырого мяса, попить теплой пульсирующей кровушки — побыть ближе к природе=коду, багам, валящемуся продакшену, бородатым админам, поспать пару ночей в серверной и… научиться обходиться подорожником, вместо туалетной бумаги. Минимализм и желание делать просто и ясно — позволит команде попадать в оценки гораздо чаще, а клиенту — взлететь побыстрее. По сути, нужно как можно быстрее воспитать и внедрить в проект эту спасительную культуру.
Забавно, но иногда попадаются такие злоупотребления оценками, вызывающие у опытных инженеров лишь улыбку:
Если вы дочитали пост до этого момента, то, очевидно, вы не уже не относитесь к категории «чем больше бумаги, тем п.па чище», «вы задаете неправильный вопрос», «вы поставили задачу не математически», а действительно хотите сделать программный проект в адекватные сроки и за разумные деньги. Зафиксируем следующие, действительно работающие практики:
Надеюсь, стало ясно и очевидно, что даже если требования к программному проекту очень четкие и формализованные (такое бывает, правда редко), может возникнуть, по неопытности инженера или аналитика, столько внезапных сюрпризов, что… хорошо работает только интуиция и метод аналогий. Разберем примеры сюрпризов — врага нужно знать в лицо:
Учитывая вышеизложенные неустранимые риски, принято действовать иначе — методом системной бункерной войны (вспомним StarCraft) и тактики: использовать зарекомендовавшие себя инженерные практики и инструменты и верить, что придерживаясь данной тактики, мы достигнем стратегических целей. Скажу проще то же самое: если отжиматься, бегать, жать экспандер и делать планку по вечерам, то вероятность дойти до дома вечером гораздо выше. Если же планировать защиту от хулиганов в диаграмме Ганта, рассчитывая вероятность попадания на 2 или 3 человек в зависимости от пути домой и времени года — то будет и сложнее, и гораздо дольше и любые изменения вероятностей нужно будет каждый день учитывать :-) Мы друг друга, в общем, поняли.
Обложив проект правильными инструментами командных коммуникаций и приняв простую, но верную систему тактических ценностей и передав, по мере возможности, их клиенту — шансы вписываться в оценки и релизы значительно повышаются. А больше гарантий нам никто и не даст — это правда жизни.
Подведем итоги. Если кратко, то мы с разных сторон увидели, что умно-длинно-политизированные методики оценки программных проектов в зайчико-попугая-часах работают только на тестовых данных в идеальных условиях, но не на практике. Ситуация повторяет подходы и результаты в машинном обучении — можно много и долго учиться, чтобы понять, что работает только интуиция/опыт/аналогия. Все заранее детально разобрать на формальные кубики — чрезвычайно дорого и на это времени, как правило, нет. В реальных условиях для оценки лучше всего полагаться на метод аналогии, простые приоритезированные списки фич, без всяких иерархий и взаимо-зависимостей. Разработчикам — делать код самодокументируемым, не надеяться на сразу-протухающее ТЗ и писать автотесты к коду. Внедрение и следование ценностям максимально открытых коммуникаций, визуализации требований программного проекта, теплая и вдохновленная атмосфера, простые категорийные оценки — сделают для попадания в срок релиза гораздо больше, чем бесконечные сдвигания абстрактных палочек в диаграммах Ганта и иже с ним. В этом и только этом случае есть все шансы увидеть команду проекта с шампанским в руках, с улыбками, отмечающим завершенный релиз, совпавший с Новым Годом. А про мумию менеджера в серверной — вам просто показалось :-)
С наступающим праздником всех и хорошего настроения!
Мы продолжаем серию публикаций «без купюр» о проектах, связанных с разработкой, часто с приставкой «веб». Сегодня поговорим о том, как наиболее правильно и быстро проводить оценки работ и планировать релизы программной системы. Скорее всего, начинающие менеджеры и энергичные и ищущие себя разработчики будут шокированы рекомендациями, но, поверьте — цель стоит одна и только одна: помочь и сделать из вас настоящего джедая, который и пользу компании приносит, и проекты двигает, да и людей развивает одновременно. Такого джедая, который искренне не заслуживает быть обнаруженным в виде мумии в темной серверной между стойками с веб-серверами и базами данных веб-проекта, летящего в будущее без душевно документированного кода, ТЗ — лишь на энергии чистого «ХЗ». Итак, поехали!
Перформанс и близкие аналоги
Важно, крайне важно, особенно ключевой проектной силе — разработчикам, отличным специалистам, ежедневно покачивающим скилы в современных IDE, понять, что отсутствие здравого смысла в оценке работы начинается еще прежде желания «зачать идею». Особенно часто это происходит в веб-разработке, где во время проведения тендера нужно взять и сделать вид, что политизированная проблема курицы и яйца имеет «строгое решение»:
- Клиент еще не знает чего хочет, либо знает очень размыто и противоречиво (т.е. не знает, но сильно хочет и, главное, в срок!)
- Клиент хочет, чтобы инженеры рассчитали стоимость «пока не знаю чего» и обижается, если они не очень попадают в данную оценку
- Клиент хочет, чтобы инженеры вписались в сроки и запустили «пока не знаю чего», скажем, 1 сентября и чтобы, разумеется, у «пока не знаю чего» не было ошибок
- Клиент нередко делегирует уточнение деталей «пока не знаю чего» ниже по иерархии сотрудникам, которые, что удивительно, начинают играть в «прятки разума», отшучиваться, шаркать ножкой, хлопать дверкой и тянуть резину!
Станет немного легче, если найти близкие аналогии странного вышеописанного перформанса в окружающей природе:
- красивое ухаживание самца за самкой до… бытовых разборок на кухне
- покупка картошки на рынке
- гадание на кофейной гуще, астрология, нумерология
- жертвоприношения Ктулху и т.д.
Понятно, что пока легче не стало, особенно если вспомнить, что в перформансе нередко участвуют «дипломированные психологи» с обеих сторон, умеющие выглядеть убедительно, решительно, говорящие «да, конечно, сделаем!» и не понимающие базовых принципов разработки программного обеспечения. А если вспомнить, что иногда «выглядящие уверенно» на обеих концах проекта пересекают линию фронта, братаются, объединяются вместе и начинают прямо искренне негодуя что-то требовать конкретное от инженеров, не предоставляя четких формализованных ответов на четко поставленные вопросы… — прямо хочется уехать в академический отпуск в Антарктиду и забыться, обняв пингвинов и холодноводных, но не менее красивых от этого, русалок :-)
Толчок любви
Трезво и аналитически строго воспринимать вышеописанный перформанс инженерам довольно больно, до кровоточения из глаз, поэтому совершают несколько известных психологических шагов, приближающих конкретику и реальную работу:
- Нужно улыбнуться друг другу
- Нужно сказать да, даже если уверенности НЕТ
- Нужно пообещать прийти друг другу на помощь
- Нужно постучать себя по груди (как КинКонг) и продемонстрировать уверенность!
Нужно поклясться в любви до гробовой доски
А если говорить серьезно, то на данном этапе нужно очень четко всем членам проектной команды осознать:
- что предстоит еще разбираться в деталях и всплывает куча интересного и неожиданного, но раз уже улыбнулись друг другу, то получится это вместе решить
- если назначен дедлайн, то нужно как можно быстрее распутать эмоциональную кашу, прикинуть и начать делать самые важные по нисходящей вещи и что-то всегда будет не сделано и это правильно
- чем больше эмоционально-политической каши в начале, тем больше времени нужно выделить на фазу анализа и проектирования
Итого, в конце перформанса должен произойти уверенный толчок вперед в неизвестное будущее, причем в хорошем, бодром настроении и взаимном желании слушать и слышать друг друга.
«Мертворожденные» проекты
К сожалению, иногда буквально сразу возникает понимание, что запускаемый проект… никому не нужен, подергается, замрет и будет выброшен в архив:
- У проекта нет четкой, харизматичной цели. Нужно просто чем-то заняться, ибо неясно, чем заняться более важным. Поэтому нужно заняться ХОТЬ ЧЕМ-ТО, зарплату то начисляют — должна быть причина :-)
- Наблюдаются попытки найти не «двигателей» проектной команды, энергичных людей, вдохновляющих себя и других и верящих в достижимость цели, а — ищут ответственных (на которых можно будет свалить все, в случае проблем). Почувствуйте разницу.
Эффективные типы перформансов
Отрадно, но частенько попадаются и правильные старты проектов, которые можно выделить по следующим признакам. Придерживайтесь этого списка и старайтесь попасть в такие команды всеми правдами и неправдами:
- Есть один или несколько человек, горящих идеями и искренне верящих в достижение цели. Харизма и тепло, исходящее от них, позволят проектной команде быть гибкой и сглаживать возникающие недопонимания и косячные оценки.
- Со стороны клиента есть адекватное осознание неопределенности собственных желаний, рисков и желание идти навстречу инженерам. Есть осознание, что предстоит много раз напрячь голову и подумать, даже если ты, как клиент, уже за все заплатил.
- Со стороны клиента либо есть, либо… ЕСТЬ понимание необходимости привлечь критическую массу «серого вещества» в виде адекватного аналитика (ов) и экспертов в предметной области, способных без «э… ы… вау...» объяснить инженерам тонкости бизнес-логики предстоящего проекта.
- Со стороны клиента есть желание достигать бизнес целей как можно более быстрым и коротким путем. Вспоминаю проект, где клиент хотел и много времени потратил на «красивую, навороченную админку веб-проекта» для сотрудников и серьезно упустил лежащие на поверхности бизнес-задачи.
Но имейте в виду — встреча с подобным подготовленным клиентом будет означать для инженерной команды спуск с IT-небес обетованных, пот, труд и кровь. Из вас вытрясут все знания шаблонов проектирования, научат писать простой код сразу без ошибок и желание вместо скриптика на PHP из 20 строк сделать фабрику классов вы будете отбрасывать как бесовское искушение. С утра, налив кофе, вы с удивлением обнаружите, что клиент, после (после!) вашего отдела тестирования, нашел и зарегистрировал в багтрекере еще 30-40 багов и рекомендует вам (вам!) еще тщательнее писать юнит-тесты и поменять мозг тестировщикам… Но зато это хорошо прокачивает :-)
Так как же оценивать программный проект?
Буду говорить прямо. Разумные люди, в т.ч. инженеры, понимают, что оценить еще не придуманное, мягко говоря, нельзя… Можно только уверенно соврать. Но, как известно, формальная математическая логика работает не у всех, поэтому иногда, все же, вы будете встречать собеседников, утверждающих что 1 + 1 = 11, причем так убедительно, что на глазах даже слезы могут появиться.
Но выход — есть: аналогия. Не зря в современном Agile подходе именно аналогия используется как фундаментальный кирпичик оценки. Работающие примеры аналогий в веб-разработке:
- Нужно сделать типовой интернет-магазин. А мы уже делали их парочку. Озвучиваем оценку с поправкой на адекватность клиента/опытность команды в виде числа Фибоначчи.
- Оцениваем фичу в story-points, а не в человеко-часах. А 1 store-point принимаем за трудоемкость создания, допустим, инфоблока со списком новостей.
- Иногда можно грубо определить тип веб-проекта по числу стандартных модулей в нем и доли кастомизации. Если были похожие типы проектов с аналогичными или близкими наборами модулей и кастомизацией — можно пользоваться аналогией смело.
- Иногда дают примерную оценку, измеряя толщину ТЗ в миллиметрах. Я совершенно серьезно — видел и, на удивление, работает.
Важно использовать подход с аналогией и к квалификации команды:
- Эти балбесы форму поиска неделю вчетвером прикручивали и потом 2 недели баги правили. Умножаем оценку на 10.
- Этот разработчик может сайт интегрировать с версткой за неделю. Добавим еще 3 дня сверху за хорошее поведение.
Как-то так. Да, вы можете возразить, а как же PMBoK, диаграмма Ганта, Velicity, карточки в Канбане, толстые книжечки по «Agile Estimation», ускорение команды, метрики, петрики?
Машинное обучение и estimation
Вас будут 5 лет учить 50 видам математики в ВУЗе, потом еще полгода на дорогих курсах про DataScience и MachineLearning, а потом на практике вы внезапно узнаете, что… научного подхода в этой области нет, нужно перебирать все варианты гиперпараметров, только времени на это вам никто не даст (дни и месяцы) и остается божественный рандомный перебор и, самое важное, ИНТУИЦИЯ. И ничего не остается, как… возвращаться и начинать читать теорию на курсах. Так и с оценкой работы в программных проектах — теории много, а работают на практике лишь крупицы знаний, замешанные на глубокой интуиции и, что одно и то же, опыте.
Чтобы действительно научиться оценивать трудоемкость программирования, нужно уехать из городов, пожить с аборигенами, поесть сырого мяса, попить теплой пульсирующей кровушки — побыть ближе к природе=коду, багам, валящемуся продакшену, бородатым админам, поспать пару ночей в серверной и… научиться обходиться подорожником, вместо туалетной бумаги. Минимализм и желание делать просто и ясно — позволит команде попадать в оценки гораздо чаще, а клиенту — взлететь побыстрее. По сути, нужно как можно быстрее воспитать и внедрить в проект эту спасительную культуру.
Известные злоупотребления
Забавно, но иногда попадаются такие злоупотребления оценками, вызывающие у опытных инженеров лишь улыбку:
- Пишется огромное ТЗ на 1000 страниц, которое начинает устаревать и «пахнуть» уже не следующий день. Никто его до конца не читал, зато на него часто ссылаются. Оно противоречиво, водянисто, политично и неэротично. Зато его оценили, порезали на итерации, их тоже оценили и теперь все стараются вписаться в этот логический ад
- Создается огромная диаграмма Ганта. Т.к. требования постоянно обсуждаются и меняются, выделяется отдел по двиганию полосочек в диаграмме Ганта — сидят и двигают целый день
- Фичи оцениваются и хранятся в почтовом ящике. Никто, кроме менеджера, не видел все фичи и оценки. Менеджер вдруг сводит счеты с жизнью и проект… закрывается.
- Доски и маркеры имеются, но фломастеры — либо давно высохшие, либо перманентные и написав что-то нецензурное на доске во время показушной коммуникации и оценки, стереть его, оказывается, уже невозможно :-)
Полезные и работающие практики оценки в программных проектах
Если вы дочитали пост до этого момента, то, очевидно, вы не уже не относитесь к категории «чем больше бумаги, тем п.па чище», «вы задаете неправильный вопрос», «вы поставили задачу не математически», а действительно хотите сделать программный проект в адекватные сроки и за разумные деньги. Зафиксируем следующие, действительно работающие практики:
- «Просто, средне, сложно». Да, советуемся с экспертом-разработчиком, либо командой и ставим на каждую фичу в ProductBacklog оценку из 3 возможных. Желательно пройтись по всем известным фичам проекта и поставить хотя бы такую оценку. Можно и нужно, имея только это на руках — уже планировать релизы.
- «Planning poker». На эту тему много информации, но если обеспечить во время оценки здоровую и позитивную атмосферу коммуникаций и доверия между вами, членами команды и клиентом, то работает неплохо.
- «Звонок другу». Если у вас есть либо в компании/команде, либо на стороне, знакомый эксперт-разработчик — поговорите с ним. К сожалению, иногда команды сговариваются и пытаются растянуть время — эксперт может дать адекватную оценку реализации.
- Фичи и коммуникации максимально визуализируются. Выделяется отдельная (ые) пробковые доски, на них висят листочки с фичами, люди подходят, обсуждают, рисуют на других досках, у которых, внимание, лежат не высохшие фламастеры и работающая стиралка. Вот отличный ресурс на эту тему.
Инструменты и эффективные практики — часто важнее планов и сроков
Надеюсь, стало ясно и очевидно, что даже если требования к программному проекту очень четкие и формализованные (такое бывает, правда редко), может возникнуть, по неопытности инженера или аналитика, столько внезапных сюрпризов, что… хорошо работает только интуиция и метод аналогий. Разберем примеры сюрпризов — врага нужно знать в лицо:
- Даже если создаваемые законодательными органами власти во всем мире законы нередко могут содержать воду и логические противоречия, вызывающие физическую боль мозга, то что говорить о ТЗ. Естественно, когда противоречие обнаруживается, требуется срочно внести изменения в код. Изменение вносится быстро, а система ломается после этого так, что восстанавливается N-дней и предсказать N научно ну никак нельзя!
- Обнаруживается конфликт программных библиотек и нужно либо одно из них отключать, либо гладиолус. Предсказать простой нельзя.
- Во время даже небольшой нагрузки обнаруживается неадекватность выбранных алгоритмов (недооценили алгоритмическую стоимость сценариев использования), из-за чего система начинает тормозить. Найти и устранить проблему можно как за часы, так и месяцы. Предсказать невозможно. Опыт, только опыт, либо коробочные решения.
- Ведущий разработчик переутомился перед релизом и начал, под влиянием нахлынувших эмоций, мочиться в серверной на стойку с веб-балансировщиками. Железо закоротило. Внезапный простой — 2 дня.
Учитывая вышеизложенные неустранимые риски, принято действовать иначе — методом системной бункерной войны (вспомним StarCraft) и тактики: использовать зарекомендовавшие себя инженерные практики и инструменты и верить, что придерживаясь данной тактики, мы достигнем стратегических целей. Скажу проще то же самое: если отжиматься, бегать, жать экспандер и делать планку по вечерам, то вероятность дойти до дома вечером гораздо выше. Если же планировать защиту от хулиганов в диаграмме Ганта, рассчитывая вероятность попадания на 2 или 3 человек в зависимости от пути домой и времени года — то будет и сложнее, и гораздо дольше и любые изменения вероятностей нужно будет каждый день учитывать :-) Мы друг друга, в общем, поняли.
- Доски, маркеры, вики — для максимально открытых коммуникаций между собой и с клиентами
- Округление проекта. Вместо убивающей коммуникации и вводящей потоки искаженной информации и медленно-испорченных телефонов иерархии — проект округляется так, чтобы все члены команды и представители клиента были доступны на расстоянии локтя
- ТЗ не где-то, а развешано на досках, стенах и как можно больше людей могут его «почитать» и обсудить
- Доступные инструменты оценки по аналогии, архив предыдущих оценок, доступный всем желающим
- Разработчики пишут автоматизированные юнит, модульные и интеграционные тесты к коду. Грубо тестов должно быть столько, сколько кода
- Обычно в любом программном проекте есть несколько мест, которые покрыты туманом и в их омутах водятся демоны. Нужно как можно быстрее поднять прототипы, отражающие данные места и провести нагрузочные и иные испытания и получить по ним оценку. Данная оценка очень пригодиться на поздних стадиях проекта
Обложив проект правильными инструментами командных коммуникаций и приняв простую, но верную систему тактических ценностей и передав, по мере возможности, их клиенту — шансы вписываться в оценки и релизы значительно повышаются. А больше гарантий нам никто и не даст — это правда жизни.
Итого
Подведем итоги. Если кратко, то мы с разных сторон увидели, что умно-длинно-политизированные методики оценки программных проектов в зайчико-попугая-часах работают только на тестовых данных в идеальных условиях, но не на практике. Ситуация повторяет подходы и результаты в машинном обучении — можно много и долго учиться, чтобы понять, что работает только интуиция/опыт/аналогия. Все заранее детально разобрать на формальные кубики — чрезвычайно дорого и на это времени, как правило, нет. В реальных условиях для оценки лучше всего полагаться на метод аналогии, простые приоритезированные списки фич, без всяких иерархий и взаимо-зависимостей. Разработчикам — делать код самодокументируемым, не надеяться на сразу-протухающее ТЗ и писать автотесты к коду. Внедрение и следование ценностям максимально открытых коммуникаций, визуализации требований программного проекта, теплая и вдохновленная атмосфера, простые категорийные оценки — сделают для попадания в срок релиза гораздо больше, чем бесконечные сдвигания абстрактных палочек в диаграммах Ганта и иже с ним. В этом и только этом случае есть все шансы увидеть команду проекта с шампанским в руках, с улыбками, отмечающим завершенный релиз, совпавший с Новым Годом. А про мумию менеджера в серверной — вам просто показалось :-)
С наступающим праздником всех и хорошего настроения!
