Грань между карго-культом и эволюцией в обучении успеху

Предприниматели с большим энтузиазмом берут на вооружение инструменты верификации будущей прибыли. Идея A/B-тестирования упала в благодатную почву. Больше нет необходимости ломать голову над цветом кнопки, можно сразу же тестировать и выбирать лучшее.

Напомню как это делается: вы создаете две страницы, разница которых будет заключаться только в цвете кнопки “оформления заказа”. Затем вы, случайным образом, половине посетителей сайта показываете страницу №1, а другой половине — страницу №2. В результате, на одной из страниц, пользователи нажмут кнопку оформления заказа больше, чем тоже самое количество других пользователей на другой странице.

Следует ли из этого, что цвет кнопки влияет на количество оформленных заказов? Давайте проведём мысленный эксперимент. У нас будет две команды, по пять человек в каждой. Одна команда будет в красных футболках, другая — в синих. Каждый член команды будет подбрасывать монетку и записывать что выпало: орёл или решка. Пусть каждый подбросит монетку, скажем, три раза. После, посчитаем количество полученных “орлов” для каждой из команд.

Мы увидим, что одна из команд набрала больше “орлов” чем другая. Можно ли сделать вывод, что цвет футболки определил победителя? Следует ли нам одевать красную (синию) футболку, когда мы собираемся зарабатывать больше “орлов”?
(далее…)

Как мы боролись с проблемами производительности в «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. Казалось бы очень разумно выслушать человека, формализовать его монолог и согласовать результат с ним же — это быстро и не затратно. Одно плохо — на этапе анализа адекватности результата моделирования деятельности (если такое предусмотрено) происходит отбраковка собранных данных по причине их несогласованности и противоречивости, процедуру сбора данных о ходе процесса надо повторять сначала, «на радость» всем участникам проекта. Почему такое происходит? Как видно из заголовка, дело в респондентах. Ниже на конкретных примерах из личного опыта я покажу, почему был сделан такой вывод и как с этим бороться.
(далее…)

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

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

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

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

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

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

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

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

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

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

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

(далее…)