Рубрика «управление проектами» - 305

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

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

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

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

«Нам за это не платят» — эту фразу я нередко слышу от окружающих и ни разу не слышал от своих сотрудников. По своей разрушительности и негативу, на мой взгляд, это одна из самых отрицательных реакций, с которой можно столкнуться. И дело тут не только в её проблемности для компании, не только в угрозе срываемых сроков, обязательств и зарождении конфликта, в звоночке по поводу низкой мотивации, а в самой сути фразы. В ответ на неё мне зачастую хочется реактивно ответить – «не нравится — уходите». В условиях текущего рынка, когда не компания выбирает сотрудника, а сотрудник компанию, когда конкуренция на ранке за ценные кадры со стороны компаний лишь обостряется найти место себе по душе – не такая уж большая проблема. Что же их держит? Неуверенность в себе? Нежелание перемен? Безответственность? К работе, и самому себе?Читать полностью »

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

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

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

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

Читать полностью »

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

Читать полностью »

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

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

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

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

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

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

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

Какие результаты это дает

  • Команда разработки может наблюдать жизнь продукта во времени, как происходит обновление, внедрение и использование выпускаемого продукта.
  • Сам продукт становится быстрее, надежнее и удобнее. Показательный пример: время, необходимое для установки и настройки серверной части продукта Acronis Access (система для безопасного обмена данными в корпоративной среде), сократилось с нескольких дней до получаса.
  • Команды маркетинга и продаж получают готовый case study, пригодный для дальнейшего распространения среди существующих и потенциальных пользователей продукта.
  • Ну, и самое главное, все в компании получают дополнительную уверенность, что новая версия продукта готова к использованию в реальных условиях.

Продукты в нашем окружении

  • Наш флагманский продукт Acronis Backup Advanced вот уже на протяжении многих лет бэкапит все бизнес критичные сервера в компании, и не раз восстанавливал их в случае аппаратных сбоев или применялся для случаев миграции на новое «железо».
  • Acronis Snap Deploy излюбленный HelpDesk инженерами продукт, который за считанные минуты разворачивает образ системы с необходимым софтом для новых сотрудников: разработчиков, тестировщиков, бухгалтеров, специалистов технической поддержки и т.д.
  • Согласно политике компании для безопасного доступа, синхронизации и совместного использования корпоративной документации, мы все используем решение Acronis Access, без которого я уже не представляю свою работу на таком же уровне производительности, и о котором я подробно расскажу в одной из следующих статей.
  • И напоследок, я не знаю таких сотрудников в компании, которые бы не использовали Acronis True Image для защиты своих персональных данных на работе и дома.

Интересный факт

«Eat your own dog food» или как мы нашли самого главного клиента
Компания Microsoft использует практику «Eat your own dog food» с 1988 года. Тем не менее в 2009 году новый CIO компании Microsoft Тони Скотт, стал продвигать новый термин «Icecreaming», аргументируя свое решение тем, что данный термин намного более привлекателен, и «мороженное это то, что наши клиенты хотели бы есть». С чем я не могу не согласиться.
Читать полностью »

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

Всем привет!

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

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

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

На тему мотивации и продуктивности написано много всего. Сотни советов, множество книг, истории из практики в интернете и на Хабре. Написаны специальные приложения, созданы сайты, постят мотиваторы и т.п., однако почему все это обычно или не работает или работает, но не долго? Почему нет способов продлить мотивирующий эффект во времени и сделать его постоянным?

image

Итак, попробуем разгадать главную тайну мотивации — как сделать эффект мотивации более продолжительным, или, в некоем идеальном случае, постоянным.
Читать полностью »

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

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

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

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

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js