Как мы боролись с проблемами производительности в «Redmine». Кто виноват и как помочь?

Как мы боролись с проблемами производительности в «Redmine». Кто виноват и как помочь?
Конечно, статья не совсем верно названа. В чистом Redmine особо больших проблем с производительностью нет. Но мы, в процессе разработки большого количества плагинов, эти проблемы с легкостью вносили.

Поэтому, статья расскажет о том, как разобраться в чем причина медленной работы той или иной функции плагина Redmine и какие инструменты могут помочь в этом. Многие советы, естественно, могут касаться не только самого Redmine, но и Rails-приложений в целом.

Симптом у проблем с производительностью всегда один – это разгневанный пользователь, кричащий, клянущий твое ПО и возможно тебя лично.
(далее…)

Крик опыта неудач

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

Это не success-story, а какой-то «way of the failures» человека, который хочет создать что-то свое, что-то классное и полезное для многих, быть честным, свободным и работать на самого себя. Если это про вас, то прошу вас, прочитайте этот пост и не наступайте на мои грабли. Уделите 10 минут. Я постараюсь говорить коротко и по существу.
(далее…)

Командная динамика по Брюсу Такману: чему нас учит опыт подводников

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

И тут нам на помощь пришел американский психолог Брюс Такман, которому довелось исследовать тысячи команд по заказу Министерства Обороны США. Военные пытались понять, как себя будут вести экипажи подводных лодок в автономном плавании. Не захочет ли кто уволиться? Или там предъявить капитану черную метку?

На основании этих исследований Такман сформулировал свой концепт, которым мы теперь с благодарностью пользуемся:

И тут необходимо вспомнить несколько историй из реальной жизни…

(далее…)

Waterfall и Agile: и всё-таки, откуда эффект?

Всем добрый день! Этот короткий пост посвящен рассмотрению моделей процессов разработки Waterfall и Agile (на примере Scrum и/или Kanban). И вот в чем дело: с точки зрения заказчика, процесс не столь важен, сколько срок и бюджет удовлетворительного с точки зрения функционала результата. И если известно, что (изменения не учитываются) затраты Waterfall-процесса идут по S-кривой, а затраты Agile-процесса накапливаются линейно (так как ресурсы используются одновременно все), то как они должны различаться по эффективности. Чтобы исследовать этот вопрос, необходимо построить модели и сравнить их, и для этого будет использована несложная математика.

(далее…)

«Eat your own dog food» или как мы нашли самого главного клиента

Словосочетание «eat your own dog food» уже давно прижилось в IT-индустрии для определения практики использования компанией или командой разработчиков собственных сервисов и продуктов. Считается, что такой подход дает ряд преимуществ, среди которых возможность собственными глазами увидеть и оценить, как продукт или сервис работает в реальной жизни, а не в условиях интеграционного, нагрузочного или какого-либо другого тестирования.

«Eat your own dog food» или как мы нашли самого главного клиента

Мы в Акронисе тоже традиционно использовали наши корпоративные продукты в собственной IT-инфраструктуре. Но долгое время четкого механизма внедрения новых продуктов и обновления старых версий не существовало. Это нередко приводило к ситуациям, когда наши клиенты начинали пользоваться продуктами гораздо раньше нас самих.
Ситуация кардинально поменялась, когда была введена обязательная приемка всех корпоративных продуктов IT-отделом компании до их релиза. Фактически, мы официально признали, что наш ИТ-отдел является нашим первым и самым главным клиентом, и что ни один наш продукт не выйдет в свет, пока он не будет удовлетворять наших первых клиентов.

Как это происходит

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

Внутренние клиенты не могут гарантировать качество продукта!
Очень важно не возлагать обязанности тестирования продуктов на внутренних сотрудников. Это не проектная команда, а ПЕРВЫЕ КЛИЕНТЫ. Продукт, передаваемый внутренним клиентам, должен соответствовать всем требованиям качества, которые установлены в компании для публичных релизов, и любые критичные дефекты, не обнаруженные во время активных циклов проекта, можно считать «факапом» проектной команды.

(далее…)

Стартап шаг за шагом

Стартап шаг за шагом

Всем привет!

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

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

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

Все врут!™ или казуистика описания бизнес-процессов

Одним из методов сбора информации о процессе является проведение интервью с владельцем или участниками этого бизнес-процесса. Такой традиционный подход встречается очень часто, особенно у начинающих бизнес-аналитиков и матерых консультантов из Big4. Казалось бы очень разумно выслушать человека, формализовать его монолог и согласовать результат с ним же — это быстро и не затратно. Одно плохо — на этапе анализа адекватности результата моделирования деятельности (если такое предусмотрено) происходит отбраковка собранных данных по причине их несогласованности и противоречивости, процедуру сбора данных о ходе процесса надо повторять сначала, «на радость» всем участникам проекта. Почему такое происходит? Как видно из заголовка, дело в респондентах. Ниже на конкретных примерах из личного опыта я покажу, почему был сделан такой вывод и как с этим бороться.
(далее…)

Планирование аварийного восстановления. Вторая часть

Готовимся к любым падениям

Планирование аварийного восстановления. Вторая часть

Это продолжение цикла публикаций, посвященных вопросам планирования аварийного восстановления. В предудущей статье речь шла об определении зоны планирования и нахождении точек отказа, которые могут приводить к сбоям в работе пользовательских сервисов. Следующий шаг – опираясь на информацию о точках отказа определить минимально возможные сроки устранения инцидентов, которые могут обеспечить технические специалисты при наличии всех необходимых ресурсов.

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

Управленческие инструменты: Мамонт как главный принцип командообразования

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

Начнем с истории. Несколько лет назад мы оказались за пивом с исполнительным директором одной крупной компании. И традиционно вместо того, чтобы пить пиво, начали обсуждать различные управленческие проблемы. Проблема, с которой столкнулись их акционеры, была стара как мир.

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

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

В процессе обсуждения мы пришли к тому, что у управленческой команды нет мамонта. Звучит странно — но про концепт командообразования «Мамонт» мы и хотели бы сегодня поговорить.

(далее…)

Как мы с помощью математической статистики измеряем качество данных в Яндекс.Городе

Летят в самолете Петька и
Василий Иванович, Василий Иванович кричит:
— Петька, приборы!
Петька отвечает:
— Двести!
Василий Иванович:
— А что «двести»?
Петька:
— А что «приборы»?

Сегодня выходит из беты наш новый сервис — Яндекс.Город. Он появился как логичное продолжение Яндекс.Справочника, который был единым источником знаний об организациях для всех наших сервисов. Его данные используются собственно в приложении Я.Город, на Яндекс.Картах, в сниппетах на странице результатов поиска, для построения маршрутов в Картах и Навигаторе, определения номера в Яндекс.Ките, выбора мест отправления и прибытия в Такси. Найти места и организации можно было на многих наших площадках, а вот выбирать там не очень удобно.

Мы поняли, что пользователям для этого нужен отдельный сервис. Но понять и сделать — не одно и то же. В этом посте я хочу рассказать о том, как мы выбирали метрики для того, чтобы измерять, что получается, какие неочевидные открытия ждали нас на этом пути, да и вообще — почему непросто оценивать качество данных в масштабах всей России или даже отдельных городов.

Если у вас свой бизнес, и если вы наемный менеджер, вам очень важно уметь измерять бизнес-показатели. Как вы поймёте, что хорошо или плохо всё работает? Как проверите, что изменения привели к улучшению? На чем вы будете основываться, принимая решения? Для всего этого нужны метрики — количественные характеристики состояния системы.

Как мы с помощью математической статистики измеряем качество данных в Яндекс.Городе
У сервиса поиска мест на Яндексе многолетняя история, и к его созданию приложили руку несколько команд. Растёт он из проекта adresa.yandex.ru. Потом Яндекс интегрировал в него бизнес «Жёлтых страниц» — так появился Справочник. Около года назад очень сильно обновилась команда сервиса. И он начал превращаться в Яндекс.Город. Я в этой команде руковожу службой производства данных и сегодня расскажу вам о том, какие у нас метрики и как они помогают нам делать лучшую базу организаций в России.
(далее…)