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

— Михаил, расскажите, чем занимались до учёбы в GeekBrains?

У меня два высших образования: педагогическое и философское. В университете, кстати, я работал последний раз в жизни. Был археологом, раскапывал исторические места разные, в основном в Москве.

А если возвращается к образованию… честно, уже почти не помню, где получал педагогическое. В Московском институте физкультуры и спорта, кажется, на факультете менеджмента спорта. Потом была армия, и после неё я подумал, что надо ещё поучиться. И получил второе высшее — на факультете философии в МГУ.

— Чем после этого занимались?

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

— Если не секрет, что за бизнес?

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

— Из-за этого управленческого опыта вы и решили выбрать продакт-менеджмент?

Это был только первый этап. Потом сменился префект, и зал закрыли. Но я к тому времени уже научился сайты делать и понял, как привлекать аудиторию. Решил, что хочу дальше в предпринимательстве развиваться. Мы с приятелем открыли офлайн- и интернет-магазин экипировки ASICS — это спортивный японский бренд. Проект просуществовал два года: я научился настраивать контекстную рекламу, с поставщиками общаться, CRM внедрять. Но средний чек в магазине, увы, был очень маленьким.

А у моего дяди было своё производство — делали интерьеры для бизнеса. И там чеки были по 500 тысяч, по миллиону. Я создал для его компании сайт, настроил контекстную рекламу, CRM внедрил. Затем мы вместе выполнили многомиллионный заказ для крупного клиента.

Потом жена вроде как в шутку попросила сделать небольшой стартап по аренде недвижимости. И закрутилось: я вышел на Фонд развития интернет-инициатив (ФРИИ), описал проект, мы прошли первый этап, второй, потом акселерацию. 

Удачный стартап получился — дважды привлекли инвестиции. Он до сих пор существует, веду о нём блог. Потом у меня появился партнёр, он занимается всей операционной деятельностью. А я решил получить профессиональное образование в том, что у меня неплохо получается. Вот так и попал в GeekUniversity.

— А как узнали про GeekBrains?

По-моему, жена нашла. Она у меня всем заведует, что-то скидывает постоянно.

— Почему все-таки решили пойти в крупную компанию? 

— Мне стало интересно. Около десяти лет я занимался только своими проектами, и мне стало интересно, как всё устроено в больших компаниях. Разместил резюме на HeadHunter, указал свои проекты, обучение во ФРИИ, рекомендации оттуда и то, что учусь в GeekBrains.

— Долго ходили на собеседования?

Где-то через две недели обучения нашёл работу. В компании было три собеседования: с HR и с двумя руководителями.

— Что самое сложное было на собеседовании?

Когда говоришь на собеседовании правду, никаких сложностей не должно быть. Если вы более-менее умеете связывать слова в предложения и действительно имеете нужный опыт, то увиливать незачем. Я сказал: «Ребята, я уже тысячу лет не работал, в принципе не знаю, как это. Я предприниматель, вот мой опыт: это умею, это знаю, тут учусь». 

— И с чем теперь связана ваша деятельность?

Теперь я работаю в крупной IT-компании. Направлений много: интернет-безопасность, продажа телеком-услуг, Wi-Fi.

— Почему захотелось работать в компании, а не в своём стартапе знания применить?

Стартап — полная неопределённость: большие риски, чужие деньги, ответственность. Это работа, в которой ты не видишь результата: не понимаешь, будет ли он когда-то. Из-за неограниченного количества задач всегда размыт фокус: и финансами занимайся, и стратегию пиши, и SMM, и всё-всё-всё. А в компании есть продукт, конкретные задачи и зона ответственности.

— Вы и стартапом продолжаете заниматься, и работаете?

Да-да. Учиться только не всегда успеваю. Уже пропустил пять занятий. 

— Расскажите подробнее про учёбу. Что стало для вас самым сложным?

Особых сложностей нет, так как контекст мне знаком по акселерации во ФРИИ. У меня даже часть заданий была готова: анализ рынка и конкурентов, MVP и прототипы, описания компании, целевые аудитории уже выделены.

— А было что-то в учёбе, что оказалось неожиданно полезным?

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

Тогда я обратился к Ване Русанову, и он нашёл ментора, похожего на меня. У него был свой бизнес, потом он занимался продакт-менеджментом. Мы подружились, и наставник очень помог мне освоиться в профессии.

— А кто этот ментор?

Женя Паршин. Вот они с Ваней — два моих ангела :)

— А по стартапу тоже с ними консультируетесь?

Да, конечно. С Ваней особенно — по любому вопросу можно советоваться. Он откликнулся, будто меня тысячу лет знает. 

Когда я пришёл на нынешнее место, мне было очень нужно структурировать работу. Вот представьте: новая для вас ниша, сложная IT-структура. Есть услуга — защита от DDoS-атак. Чтобы понять её, нужно разбираться, как работает интернет в целом. А таких услуг 34! Ещё надо понимать, как работает Wi-Fi, через какие каналы раздаётся, какое оптоволокно прокладывается… Я до сих пор сижу на совещаниях и понимаю только 5% из того, что люди говорят. Хотя они говорят по-русски. 

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

— Выходит, менторы — это переводчики на понятный язык?

Нет, они именно «структуризаторы». Они уже знают, что надо делать. Ты не разбираешься в 34 продуктах, потому что это невозможно, а просто прогоняешь их через определённый путь. Смотришь рынок, конкурентов, делаешь описание. Хаос уменьшается.

— Как бы вы описали свою роль в компании?

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

Если рассматривать более подробно, то все зависит от того, какой этап мы проходим. У меня есть бэклог — мешок с задачами. Я их приоритизирую: понимаю, какая из задач ближе к деньгам и где их больше, отбираю по другим критериям. А затем, в зависимости от этого, беру нужные продукты и через road map с ними работаю, провожу их по определённым этапам. с отделом продаж, собираю обратную связь о продуктах. Взаимодействую со многими отделами, в том числе с отделом продаж, собираю обратную связь.

— Что больше всего нравится в работе?

Сложный вопрос…

— Может всё? :)

Или ничего :) Я свободолюбивый человек, и мне сложновато ходить на работу пять дней в неделю. Понимаю, что это моё время, его больше никогда у меня не будет — и тянет сделать что-то своё. Говорю как есть.

— Понимаю вас. Но что-то всё же привлекает, раз вы до сих пор не уволились?

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

— Уже думаете, как это в своих проектах использовать? Может, свою компанию создать?

Да, уже планирую :)

— А какие ожидания были от работы? Что оправдалось и было неожиданным?

Было интересно понять, смогу ли я работать, в коллективе ужиться. Вроде со всеми ребятами хорошо общаюсь.

— Какие планы по развитию в профессии? Какие скиллы сейчас подтягиваете?

Меня привлекает менторство. Есть три человека, которых я наставляю, и мне это безумно нравится! Если бы спросили, чем я хочу заниматься в жизни, то для меня самая классная деятельность — менторство.

У меня уже был такой опыт в стартапах. Выступал наставником не столько по продукту, сколько по бизнесу в целом: делился опытом с людьми, показывал, как все процессы настраиваются.

— Учёба в GeekBrains позволяет лучше помогать людям?

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

— А что порекомендуете тем, кто учится?

Самый главный совет — не засиживаться в теории. У нас есть общий чат с ребятами из группы — и это бесконечное теоретическое обсуждение. Я считаю, что нужно быстрее выходить практиковаться. Если вы пришли с целью найти работу, то не нужно год и два месяца только учиться. Абсолютно точно можно это делать параллельно с работой. Чем быстрее вы создадите резюме, сходите на собеседование — тем лучше. Пусть даже там откажут один, два, десять раз… Я вижу проблему — люди стопорятся на этапе получения этих нескончаемых теоретических знаний.

— Информационный жир накапливают?

Да. И ещё нужно понимать, что все наши знания, скорее всего, уже устарели к моменту получения. Как ни крути, мы все получаем вторичную информацию, которая на Западе давным-давно неактуальна.

— Кому можно рекомендовать обучение на факультете продакт-менеджмента?

Если сравнивать с ФРИИ — там всё заточено на то, чтобы вы развивали стартап. А в GeekBrains — на то, чтобы вы получили профессию. Это разные вещи. Так что больше рекомендовал бы тем, кто хочет пойти работать в компанию.

В статьях об управлении продуктами часто пишут о разнице между продакт- и проджект-менеджер — наверно, потому что звучит очень схоже. Если вы смогли в этом разобраться, то вот вам другая задача, со звёздочкой: понять разницу между менеджером продукта (он же продакт-менеджер, product manager, PM) и владельцем продукта (продакт-оунер, product owner). Вопрос непростой, тем более что в некоторых компаниях предпочитают объединять эти роли, вручая все обязанности одному человеку. Можно ли так делать и в чём разница, разбираемся вместе с куратором программы курса Project Manager Дмитрием Васиным.

Кто чем занимается

Если вкратце, продакт-менеджер — лицо, которое принимает окончательное стратегическое решение по продукту: по его видению, стратегии, бизнес-цели. А владелец продукта — это роль в методологии Scrum, ответственная за достижение максимальной ценности продукта.

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

Продакт-оунер несёт ответственность за достижение максимальной ценности продукта — как результата работы команды. И добивается он этого при помощи Scrum — фреймворка гибкой разработки программного обеспечения. Владелец продукта понимает, кто чем занимается в команде, управляет бэклогом, плотно взаимодействует с разработчиками и другими заинтересованными лицами. Он отвечает за то, чтобы все члены команды имели ясное представление, над чем работают и в какой последовательности будут выполнять задачи.

Почему возникает путаница

Scrum — простая структура, ориентированная на помощь командам в разработке программного обеспечения. Она не охватывает общие практики управления продуктами: разработку стратегии, составление дорожной карты и финансовый прогноз. Единственный инструмент управления, который предлагает этот фреймворк, — приоритизация бэклога.

Есть подходы, где разделяют роли продакт-менеджера и продакт-оунера, чтобы облегчить масштабирование. Например, SAFe — Scaled Agile Framework — фреймворк для координации работы над проектом (или связанными проектами) для пяти и более скрам-команд. Владелец продукта в SAFe — не то же самое, что продакт-оунер в Scrum, так что это только добавляет путаницы. Зачем тогда в Scrum вообще введена роль владельца продукта? Почему бы в фреймворке не использовать термин «менеджер продукта»? 

Дело в том, что в 1990-х годах, когда был разработан Scrum, управление продуктами отличалось от сегодняшнего. Менеджеры продукта делали предварительные исследования рынка, планировали выпуск продуктов и определяли требования к ним. Затем они передавали спецификацию и требования менеджерам проектов, которые и занимались созданием продуктов. Затем менеджеры продукта возвращались только для того, чтобы поставить задачу на внесение правок или помочь на этапе запуска.

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

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

Чтобы начать работать гибко, в этом случае достаточно ввести должность продакт-оунера (владельца продукта). Scrum позволяет возложить эту роль на кого-то из команды — так что не придётся создавать целую группу управления продуктами и инициировать организационные изменения. Сотрудники бизнес-подразделений после обучения и инструктажа смогут выступать в качестве владельцев продуктов. Но в долгосрочной перспективе полезно выделять эту функцию отдельно.

На практике термины «менеджер продукта» и «владелец продукта» часто используются как взаимозаменяемые. Однако специалисты не играют одну и ту же роль под разными именами — это две уникальные функции. Сравним рабочие задачи:

Может ли продакт-оунер быть менеджером продукта?

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

Короткий ответ: да, владелец продукта может быть менеджером продукта — и наоборот. А если это всё-таки два разных специалиста, то крайне важно, чтобы они понимали, чем различаются их роли и обязанности.

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

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

Материалы для дальнейшего изучения

• Руководство по Scrum — исчерпывающее описание правил игры, ролей, событий, практик и ценностей. Это первое, с чего нужно начать изучение фреймворка.
• Product Manager vs Product Owner — статья одного из совладельцев компании Silicon Valley Product Group Марти Кегана. Он участвовал в разработке многих успешных продуктов, был старшим вице-президентом по управлению продуктами и дизайном в eBay, а до этого — вице-президентом в AOL и Netscape Communications, инженером-программистом в HP Labs.
• Описание ролей в SAFe — информация о гибком фреймворке, который позволяет использовать Agile-методологии в больших командах (от 50 человек).

Менеджер продукта — увлекательная профессия, освоить которую можно на факультете GeekUniversity. За 14 месяцев обучения вы вместе с дизайнером и командой разработчиков создадите свой продукт и на собственном опыте узнаете о множестве нюансов работы продакт-менеджера.

На связи технический директор Calltouch Роман Хохлов. Роман несколько лет исследовал методологию управления процессами в компании. За это время он сформулировал перечень базовых элементов организации командной работы, и в этой статье Роман готов поделиться своими наблюдениями.

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

Командообразование

За любыми процессами разработки и производства продуктов стоят люди. Приступая к управленческой работе, вам придется учитывать возможности своей команды. Эффективность работы напрямую зависит от вашего умения выстраивать взаимодействия внутри коллектива. Если умеете – команда продуктивно трудится. Не умеете – всё идет вразнос.

Основные проблемы и барьеры

Слабые звенья. Первая причина – в команде собраны неравноценные специалисты. Вторая – участники не задействуют свои сильные стороны. В любом случае коллективный процесс спотыкается о человеческий фактор.

Непонимание масштабов. Группы из 5, 25 и 100 человек – это совершенно разные структуры. У каждой такой команды свое восприятие целей и условий их достижения. Если руководитель не учитывает законы развития своей группы, начинаются перекосы. Например, механизмы, свойственные крупным компаниям, внедряются в малые коллективы. Обратный пример, попытки сплотить десяток департаментов корпорации через тимбилдинги.

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

Практический опыт решения

Два года назад перед компанией встала задача оптимизации процессов. Начали с кадров.

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

Второй шаг. Ротация. Оказалось, что некоторые разработчики лучше справляются с задачами, от которых были удалены длительное время. Мы перенаправили одного способного программиста с багфиксинга на передовую разработки. Что это дало? За 2 месяца создали модуль распознавания пола по звонкам и заявкам. Один из мощных и передовых в экосистеме Calltouch.

Ротация – это незаменимый инструмент, который помогает:

• выявить сильные стороны сотрудника;
• получить сотруднику ценные навыки из смежных направлений;
•  повысить вовлеченность сотрудника в общий процесс.

Здесь мы подходим к вопросам масштаба и личной составляющей процессов. В нашем коллективе численностью до 20 человек мы можем себе позволить:

• сплоченную команду с сохранением человеческого отношения в рамках структуры;
•  ежедневные митинги целым отделом, где каждый имеет право слова;
•  вникать в полный спектр продуктов и услуг компании;
• создавать вовлеченную команду в процессе разработки продукта. Изначально вокруг проекта создается очаг – ключевые сотрудники. Рядом с ними обозначается эпсилон-окрестность вовлеченности. В неё попадают сотрудники из других проектов по правилу ротации.

Разрастаясь, проект постепенно выходит на взаимодействие целых отделов. Перемещаются и взаимодействуют уже не только люди, но и команды.

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

Что следует помнить:

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

Механика рабочего процесса. Приоритизация задач

Закончив с командообразованием, руководителю следует обратить внимание на следующий метод эффективного управления - механику процессов. Как и откуда задачи поступают в отдел? По какому регламенту они выполняются? Что с ними происходит далее?

Основные проблемы и барьеры

Отсутствие планирования. Без четкого плана и приоритетов, команда выполняет задачи несогласованно. Как результат – нестыковки в проекте, хаос в работе сотрудников. В нашем случае можно выделить три источника задач:

• Продакт-менеджеры формируют задания на разработки новых или улучшение существующих продуктов.
• Техподдержка работает с жалобами пользователей. Собирает информацию о неполадках и передает на исправление разработчикам.
• Повестка отдела разработки по созданию и модернизации продуктов/процессов.

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

Отсюда проистекают попытки сделать всё и сразу. Без серьезного планирования и расстановки приоритетов. В итоге от такой работы получается скоп недоделанных модулей и критических ошибок.

Разрывы между этапами проекта. Когда плана совместной работы нет, возникают перекосы в командном процессе. Например, группа разработчиков закончила свой объем работы. Она уже готова передать эстафету коллегам, но те завязли в параллельном проекте. Через несколько недель они принимают фронт работ первой команды. Тратят несколько дней, чтобы вникнуть в суть задачи. Только после этого включаются в работу.

Что случится, когда они выполнят свою итерацию и вернут модуль на доработку? Разработчикам понадобится время, чтобы вспомнить проект и перестроится.  

Бесконечные итерации. Когда у руководителя нет внятного плана работы над проектом, страдает вся команда. Сотрудникам ставятся неверные приоритеты, даются беспорядочные указания. Разработчикам подкидывают новые «хотелки» менеджеров раз в час. В итоге проект буксует.

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

Практический опыт решения

Как мы поступили.

Разгребли мусор. Первым делом – прибрались в багтрекере. Процесс разработки прилично ускорился. Со стороны казалось, что мы налегли на новые разработки, забросив работу над ошибками. Всё ровно наоборот. Драйвером роста стало то, что мы избавились от груза ошибок.  

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

Обозначили свои возможности другим отделам. Далее – договорились с продакт-менеджерами о соблюдении четкого алгоритма взаимодействия. У нас есть свой четкий распорядок. Доработки без критического статуса – терпеливо ждут очереди.

Процесс разработки подчиняется концепции таймфреймов:

• Совместно с продакт-менеджерами составляем квартальный план. В документе прописываем идеи с высоким приоритетом и перечень задач.
• Рабочий процесс делится на недельные спринты.
• Ежедневные митинги помогают держать друг друга в курсе происходящего. Общаясь командами, мы можем изменять вектор развития.

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

•  Ценность спринтов в том, чтобы сориентировать разработчика по предстоящей итерации. Нам важно не загнать всех под дедлайн, а дать панорамную картину процесса.
• Лучше взять меньше задач и по мере выполнения добрать новых. Мы решили не брать на себя больше, чем можем выполнить за определенный отрезок времени. Такой подход дал результат. Мы перестали распыляться и сфокусировались на узком круге задач.

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

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

Культура и концепция управления

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

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

Забудьте про KPI. Здесь важно соблюдать меру. Не нужно отказываться от измеримости бизнеса. Напротив, эффективно управлять без измерений результатов невозможно. Но любые измерения должны быть адаптивны и соответствовать реальности.

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

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

Нет явных оценок времени и трудозатрат. Вместо жестких дедлайнов, мы управляем изменениями. Самоорганизация и быстрая реакция помогает нам корректировать процессы на ходу. Например, завтра разработчик Фёдор под настроение зафиналит проект, на который отводилась неделя. А Пётр вдруг заболеет и не выдаст новое обновление в срок. Тогда остальные участники подхватят буксующий процесс. Так или иначе, на выходе мы получим рабочий продукт точно по графику.

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

Результаты

За первый год мы улучшили на 80% показатели планирования сроков. Согласно статистике в JIRA:

• В июне 2017 закрыто 96 багов, 85 тасков
• В июне 2018 закрыто 99 багов, 147 тасков
• В июне 2019 закрыто 105 багов, 213 тасков 

До анализа данных, нам казалось, что ошибок за год стало меньше. Но JIRA свидетельствует об обратном.

• Это обусловлено возросшим количеством новых продуктов. Однако в пересчете на один продукт багов стало меньше.
• Мы разгребали «мусор» багов за прошлый год.
• Приоритизация приносит свои плоды. Мы четко поняли, в каком порядке работать с ошибками. Стали устранять баги быстрее.
• Базовые меры по командообразованию позволили повысить качество исполнения проектов.

На текущий момент, устранение багов занимает один день в неделю из пяти.    

В бэклоге значительно уменьшилось количество задач по сравнению с первым годом. Если в 2017-м там было более 350 задач, то в 2019-м их около 180. При этом оба года наблюдается рост компании. Мы выпускаем больше продуктов.

Для сравнения. По состоянию на 2 квартал 2017 года мы не выполнили ничего, чтобы стабильно работало. За 2 квартал 2018 году создали около 30 новых задач различной степени сложности. Одним из драйверов успеха стала работа продакт-менеджеров. Они стали заблаговременно прорабатывать и ставить задачи, что сильно улучшило общий процесс.

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

С рабочим распорядком в офисе проблем почти не бывает. Там все отрегулировано: установлено рабочее время, прописаны обязанности, определены приоритеты задач. Есть руководители, перед которыми нужно отчитываться, а еще совещания, встречи, отчеты, премии и штрафы. В общем, вся система выстроена так, чтобы работник не забывал о своих обязанностях.

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

Никто больше не требует отчет «срочно к 16 часам» в 15:30. Кажется, что можно расслабиться и работать в свое удовольствие. Выстроить день так, как давно мечталось: чтобы успеть и выполнить задачи, и заняться спортом, и встретиться с друзьями.

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

И вот тут начинается самое интересное.

Все фрилансеры делают это

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

Она скосила даже самых стойких — тех, кто изо дня в день спокойно отказывается от соблазнов и работает по 4–6 часов в сутки, решительно не понимая, «что тут такого сложного». Да, такие люди существуют. Но и эти киборги нет-нет да и признаются в грехе ничегонеделания. Выглядит это, конечно, как если бы атлет пожаловался на насморк 200-килограммовому диабетику. Но факт остается фактом — все фрилансеры испытывают трудности с организацией свободного рабочего дня.

И все так или иначе сражаются с гидрой из чувства вины, стыда, выгорания, усталости и депрессии — нужное подчеркнуть, ненужное подождать. 

Хорошие новости: с этим можно работать, это можно контролировать.

Соберись, тряпка!

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

Лень или отдых?

К сожалению, лень до сих пор считается ужасным пороком. Признаться в ней порой стыднее, чем в смертных грехах. Лень принято искоренять, с ней обязательно нужно бороться — ведь только трудолюбивый человек может чего-то достичь!

Но попробуйте остановиться и перестать винить себя. Задайте своей лени вопросы — почему и зачем она появляется и что значит для вас? Может, вы работаете с неприятным заказчиком, поэтому хочется все бросить и смотреть смешные видео? Или выполняете нудную работу без стимула? А может, трудитесь уже больше 10 часов подряд и просто нуждаетесь в отдыхе? А самое неприятное — если делаете то, что давно уже не приносит удовольствия.

Честно отвечайте на эти вопросы при каждом «приступе лени» хотя бы пару недель — и удивитесь результатам.

Вы сможете решить, стоит ли изгонять лень — или просто позволить ей быть и подавать вам сигналы.

Сон — для слабаков!

В комплекте с кампанией по борьбе с ленью нередко идет установка «надо просто меньше дрыхнуть». Наверняка вы читали все эти истории о том, как здорово спать пять-шесть часов в сутки — так продуктивно! Или как прекрасно вставать в пять утра, потому что это идеальное время для работы. Да и вообще, можно спать по два часа несколько раз в течение суток — и это ну очень круто.

Разочаруем любителей таких практик.

Во-первых, недостаток сна нельзя компенсировать ничем. Почитайте, например, об Арианне Хаффингтон — известной журналистке, которая придерживалась стратегии «меньше сна — больше работы». Однажды ночью она отключилась прямо на рабочем месте, упала и сломала челюсть. После этого Хаффингтон написала книгу «Революция сна», в которой рассказала, как вернуть в свою жизнь здоровый сон и почему это важно.

Американский специалист из Центра по исследованию нарушений сна Томас Рот вычислил, сколько людей действительно могут спать по 5 часов в сутки и не испытывать ухудшения когнитивных функций. Когда ученый округлил показатель в процентах, получил 0. То есть фактически бодрствовать по 19 часов ежедневно и быть здоровым, активным и способным на полноценную умственную деятельность — это патология, а не норма. Вряд ли кто-то из нас действительно обладает этой сверхспособностью. 

Львы, дельфины и прочее зверье

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

Специалист по сомнологии (это раздел медицины, изучающий сон) Майкл Бреус написал книгу «Всегда вовремя», где разделил людей на четыре хронотипа: «дельфинов», «львов», «волков» и «медведей».

«Лев» в этой системе — привычный для нас жаворонок, а «волк» — сова. «Дельфин» — человек с хронической бессонницей, которому нужно совсем немного сна. Это крайне редкий тип, и в рамках того самого 0 % от Томаса Рота.

«Медведи» — самая интересная и многочисленная группа, их около 85 %. Утро у таких людей начинается с 7 до 11 часов, они активны в течение привычного рабочего дня (до 18) и, если дополнительно себя не накручивают, ложатся спать до полуночи.

Определить, к какому типу вы относитесь, можно по тесту. Если окажется, что вы «волк», у которого продуктивная работа начинается в 16 часов, — приступайте к задачам во второй половине дня и не испытывайте по этому поводу чувства вины. 

Принято считать, что качественно можно трудиться только в первой половине дня, а еще лучше — ранним утром. Но если вы «волк» по хронотипу, для вас эта схема работать не будет. И с первыми лучами солнца вы сможете только ненавидеть весь мир, а особенно — восторженных «львов», которые расписывают прелести раннего подъема.

Концентрация

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

Важное условие для продуктивности этих четырех часов во время свободного рабочего дня — фокусировка на том, что вы делаете. Если одновременно обрабатываете картинки, слушаете подкаст и жуете бутерброд, то глубокой концентрации нет.

Организуй это

Важно и обустроить рабочее пространство. Бывает достаточно поменять стол, купить удобный стул, правильно выставить освещение — и значительная часть проблем решится сама собой.

Если эти штуки не срабатывают, можно прибегнуть к другим приемам.

Магия таймера

Попробуйте работать по таймеру. Экспериментируйте: 20 минут работы — 5 минут отдыха, 45 — 15, 90 — 20. Пробуйте разные варианты, наблюдая за концентрацией.

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

Списки, ежедневники и все-все-все

Ведите ежедневники и составляйте списки дел, только если вам это помогает. Если вы каждый декабрь покупаете ежедневник и забрасываете его к середине января — может, зря тратите деньги? Попробуйте систему планирования Bullet journal или старые добрые стикеры. Не исключено, что вам вообще не нужно ничего из этого.

Зачем есть лягушку

Самое сложное и противное дело важно выполнить в самом начале работы, когда вы еще полны сил. Проглотить лягушку — и идти дальше. Чем дольше откладываете, тем меньше будет оставаться ресурсов на этот рывок. 

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

GeekBrains продолжает рассказывать о методологиях разработки программного обеспечения. Если вы еще не читали предыдущие тексты о методологиях «Водопад», Scrum и XP, бережливой разработке и Kanban — самое время наверстать упущенное!

Сегодня мы рассмотрим методологию, которую успешно применяет один из самых мощных IT-гигантов — компания Microsoft. Это Microsoft Solutions Framework, или MSF. С ее помощью создано большинство современных решений и проектов «Майкрософт». 

Ты помнишь, как все начиналось

История создания MSF берет начало в 1993 году. Компания Microsoft уже была ведущей в IT-сфере и искала способы повысить эффективность и отдачу от своих проектов.

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

У Microsoft был обширный опыт в создании программных продуктов и продвижении масштабных IT-проектов: были уже выпущены Windows 3.11, Office 3.0 и многое другое. Компания суммировала накопленные знания и навыки, проанализировала опыт конкурентов и в 1993 году выпустила серию руководств, посвященных организации труда разработчиков — «белые книги» MSF. 

Пять лет спустя, в 1998, была выпущена вторая ревизия MSF. В 2001 за ней последовала третья, а в 2005 вышла последняя на данный момент версия — MSF 4.0.

Отличительными чертами Microsoft Solutions Framework стали гибкость и масштабируемость. Эта методология подходит для работы в проектной группе или организации любого масштаба. MSF включает основополагающие принципы, модели и дисциплины управления персоналом, процессами и технологиями. Другим преимуществом методологии стала ее демократичность и отсутствие иерархических отношений «начальник — подчиненный». 

Основополагающие принципы MSF

Принципов, на которых базируется MSF, всего восемь. 

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

Работайте над общим видением
Данный принцип Microsoft Solutions Framework подразумевает, что все члены команды должны детально понимать цели и задачи, над которыми работает коллектив. Общий взгляд на то, каким должен быть результат, гарантирует, что усилия разработчиков будут согласованными.

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

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

Разделяйте ответственность
Все участники проекта принимают и осознают свою ответственность за порученную задачи и собственные решения.

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

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

Сотрудничайте с клиентом и сосредоточьтесь на предоставлении бизнес-ценности
Всегда нужно помнить о главном: программное решение должно представлять ценность для бизнеса заказчика. MSF требует от команды ориентироваться на клиента и вовлекать его в работу.

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

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

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

Инвестируйте в качество
Успех команды зависит от того, насколько каждый специалист осознает свою ответственность за продукт. Чтобы обеспечить высокое качество решения, на протяжении всего проекта работает группа тестирования — в ее задачи входит раннее выявление ошибок и недочетов. Обнаруженные баги надо исправлять как можно скорее, чтобы они не повлияли на разработку. Microsoft Solution Framework требует, чтобы в планы и графики изначально вносилось время на устранение недостатков. Только в этом случае можно уложиться в срок.

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

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

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

Пять «белых книг» MSF

MSF разработана как комплекс отдельных компонентов — моделей и дисциплин. Всего их пять, и они описаны в пяти «белых книгах» (white papers) MSF. 

Моделей используется две:

• модель команды;
• модель процесса.

А дисциплин в MSF три:

• управление проектами;
• управление рисками;
• управление готовностью.

Рассмотрим их.

Модель команды MSF

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

Пример традиционной иерархической организации труда

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

Команда проекта в MSF — это коллектив равноправных сотрудников. Они разделяют ответственность и свободно обмениваются опытом и информацией. Внутри команды есть ролевые кластеры (роли), отражающие функциональные обязанности конкретных специалистов. У каждой роли — свои цели и задачи, и все они считаются равноценными и одинаково важными. Роли дополняют друг друга и вместе служат единой цели — созданию качественного продукта.



Модель команды в MSF

Эту модель можно масштабировать для работы как крупных компаний, так и небольших коллективов.

Примеряем роли

Бизнес-аналитик
Это главный посредник между командой разработчиков и клиентом. Он должен детально разобраться в потребностях заказчика, определить бизнес-ценность продукта и понять, какая именно функциональность необходима в программе. Он трансформирует эту информацию в конкретные определения и требования к качеству и доводит их до разработчика. Можно считать, что бизнес-аналитик — представитель клиента в коллективе. Он управляет продуктом, чтобы тот соответствовал потребностям бизнеса и ожиданиям заказчика. 

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

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

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

Но в MSF разработчик — полноправный участник всех обсуждений. Он определяет, какое время потребуется ему для создания функциональных блоков программы. Помогает архитектору выстраивать удачную структуру проекта с точки зрения его реализации, основываясь на своем глубоком знании языка программирования. Участвует в создании дизайна приложения. В проекте считается экспертом по всем техническим вопросам, и за ним зачастую остается последнее слово в совещаниях о том, «как все это реализовать в рамках используемых технологий». 

Тестировщик
Задача тестировщика — выявить в продукте баги, проблемы и неудачные решения, которые могут негативно сказаться на качестве и снизить ценность приложения для клиента. Тестировщик обязан понимать и учитывать контекст применения программного продукта: кто, как и для чего будет его использовать на стороне заказчика. Если функция X выполняется корректно и выдает правильный результат, но его получение занимает в среднем час, тестировщик может признать ее работу неудовлетворительной — зная, что клиенту требуется выполнять эту функцию 20–30 раз в день. 

Ошибки и отклонения от заданных параметров фиксируются и документируются, после чего тестировщик передает их разработчику для исправления. Тестировщик также участвует в выработке стандартов качества и создании тестовых задач, нагрузочных тестов и подобного. 

Релиз-менеджер
В Microsoft Solutions Framework, что касается выпуска готового продукта или любой его работоспособной версии, — на релиз-менеджере. Он создает план выпуска версий, сертифицирует готовый продукт и следит за тем, чтобы программа дошла до клиента. Кроме того, в его обязанности входит информационное сопровождение версий, например описание новых функций, изменений и нововведений. 

Администратор баз данных
Если в составе продукта есть база данных, то команде не обойтись без администратора БД. Он следит за порядком в базе, ее целостностью и состоянием данных, работоспособностью серверов. В его обязанности входят все рутинные операции, обеспечивающие безопасность и сохранность информации, например регулярное создание бэкапов.

В отдельных проектах может принимать участие и разработчик баз данных. Он несет ответственность за создание структуры БД и функциональности, обеспечивающей ее работу. Частично этот специалист может пересекаться по задачам с разработчиком проекта. Есть смысл выделить эту роль, если проект сложный и базы данных играют в нем значительную роль. 

Несмотря на множество ролей, модель MSF подходит не только большим коллективам, но и маленьким командам: в этом случае каждый участник берет на себя несколько ролей. 

Методология MSF подчеркивает, что все роли — равноправны, и ни один член команды не может считаться более влиятельным или принимать решения единолично.

Модель процесса MSF

Еще один важный компонент методологии MSF — модель процесса, то есть последовательность действий, необходимых для построения IT-решения. Модель не предписывает конкретных процедур и не содержит жестких формализованных требований к процессу — при создании MSF компания Microsoft стремилась сделать ее гибкой и адаптируемой к условиям любого проекта. В MSF объединились две концепции разработки: «Водопад» и спиральная модель. 

От «Водопада» MSF досталась система вех (milestones) — особых точек в конце каждой фазы процесса, отвечающих заданным критериям завершения фазы. В этих точках команда рассматривает результаты своего труда и отвечает на вопросы «Сделали ли мы все, что планировали?», «Работает ли решение так, как нужно заказчику?», «Готовы ли мы двигаться дальше или необходимо уделить внимание доработкам?». Чтобы перейти на следующий этап, необходимо дать большинство положительных ответов.

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

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

Весь процесс разработки в MSF разбит на отдельные итерации. Каждая проходит несколько этапов (фаз).



Модель процесса MSF

1. Выработка концепции (Visioning)
Команда вырабатывает единое видение проекта или его части. Совместными усилиями коллеги решают, какая именно функциональность будет разрабатываться в ходе итерации, определяют основные концепции, которые лягут в основу разработки. Этап завершается вехой «Концепция утверждена».

2. Планирование (Planning)
Задачи, которые необходимо выполнить в ходе итерации, разбиваются на подзадачи, определяется сложность их реализации, устанавливаются сроки и назначаются ответственные. В планы закладывается время на тестирование и исправление дефектов, а также предварительно намечается, как именно будет проходить тестирование.

3. Разработка (Developing)
На данном этапе MSF создается программный код новой функциональности в соответствии с концепцией и утвержденными планами.

4. Стабилизация (Stabilizing)
К делу подключаются тестировщики. После тестирования выявленные баги и недочеты возвращаются разработчикам для исправления. 

5. Внедрение (Deploying)
Очередной релиз программного продукта передается заказчику и устанавливается на клиентских компьютерах. 

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

Дисциплины MSF

Управление проектом

В MSF это целый набор навыков и компетенций, в том числе:

• комплексное планирование всех этапов и аспектов проекта;
• управление бюджетом, расходами и ресурсами;
• подготовка графиков и контроль за их соблюдением;
• ведение административной документации.

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

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

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

Управления рисками

Риски — это факторы и события, которые могут оказать негативное влияние на проект в перспективе. В MSF есть специальный процесс, который помогает выявлять, отслеживать и минимизировать риски. Он состоит из шести шагов.



1. Определение рисков
Любой член команды в любое время может (и должен) сообщать о рисках, которые он выявил. Например, если обнаружил ошибку в сторонней библиотеке кода, которая на данный момент не беспокоит, но грозит привести к проблемам, когда будет использоваться соответствующая функциональность библиотеки. 

2. Анализ и расстановка приоритетов
Насколько серьезную угрозу представляет выявленный риск для проекта? Возможно ли избежать проблем? Требуются немедленные действия или время терпит? Необходимы ли дополнительные ресурсы, например время на поиск решения?

Все эти вопросы обсуждаются коллегиально. 

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

4. Отслеживание и отчет
Придерживаться принятого плана неукоснительно — половина дела в MSF. Любое изменение в проекте может повлечь новые риски или рецидив старых. Отслеживание рисков помогает держать их под контролем и своевременно пересматривать тактику борьбы с ними.

5. Контроль
Контроль — это исполнение планов в отношении рисков и связанных с ними отчетов. 

6. Знание
Изучая риски, команда получает новую информацию о них и о способах преодоления сопутствующих сложностей. Эти знания необходимо фиксировать и помещать в базу данных, чтобы иметь к ним доступ в будущем. 

Управления готовностью

Эта дисциплина занимается вопросами профессионального роста и подготовки специалистов.

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

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

Процесс управления готовностью включает четыре этапа:

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

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

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

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

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

В заключение

Пять «белых книг» описывают MSF в мельчайших деталях, давая точные определения ее компонентам, а также подробные описания процессов. 

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

Методология не требует применять специализированные средства компании Microsoft. Существуют системы, «заточенные» под MSF, например Visual Studio Team System — и Microsoft прямо призывает организации, использующие ее, следовать MSF. Но ничто не мешает применять MSF с любыми другими средствами организации производства.

Microsoft Solutions Framework используется уже более четверти века, помогая компании Microsoft разрабатывать новые решения и развиваться. И это аргумент в пользу методологии.

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

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

Выпуск минимальной версии продукта (MVP стартапа)

Это способ, что называется, в лоб. Очевидно же: хочешь продать — сделай продукт и продай! Но программисты часто затягивают разработку продукта и не могут его выпустить.

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

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

Другая распространенная ошибка — желание сразу все формализовать: оформить ООО или ИП, договоры между членами команды и прочее. Здесь работает тот же принцип: делайте все очень просто и очень быстро. Например, можете составить договор в свободной форме и подписаться под ним всей командой. И не спешите платить налоги, ведь вы еще ничего не заработали.

Мой опыт первых продаж MVP

Мы с напарником начали писать сервис «Скорочтец» в феврале 2018 года, а к концу июня уже была готова основная функциональность: программа курса с пятью уровнями, все упражнения (пусть недоработанные и с багами), мобильная верстка. Кстати, напарник за это время сменился.

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

Моя оценка

Скорость: 1 / 5. MVP — это самый медленный из способов. Даже в простом продукте придется потратить 3–6 месяцев, чтобы дойти до продажи.

Достоверность: 5 / 5. Зато самый достоверный. Абсолютно незнакомый человек заходит на сайт и покупает — какой эксперимент может быть чище? В случае сервиса «Скорочтец» достоверность подтвердилась десятком продаж за месяц после первой покупки.

Продажа «обещаний» в стартапе

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

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

И не бойтесь! Если даже у вас ничего не получится, вы просто вернете людям деньги.

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

Но есть и подвох: если «обещания» раскупили на ура, это не значит, что готовый продукт будут покупать так же. Реальных покупок может и не произойти, пока сам продукт не дорастет до уровня обещаний.

Мой опыт

Осенью того же 2018 года я задумал еще один продукт. Вместо курса скорочтения — читалка, в которой текст исчезает, так что пользователю некогда отвлекаться на перечитывание и он начинает читать быстрее.

Я быстро собрал прототип, сделал гифку с демонстрацией и отправил пользователям «Скорочтеца». Потом лично написал всем заинтересованным — 12 из 24 перевели мне деньги! Безумие!

Но штука в том, что пользователи представляли себе читалку по качеству ничуть не хуже, чем у «ЛитРес». Кроме того, я «обещал», что, возможно, мы создадим алгоритм, который будет автоматически генерировать вопросы по прочитанной главе (до сих пор хочу это сделать).

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

Продажи начались, только когда я интегрировал читалку в основной сервис, так что люди смогли загружать свои книги и учиться скорочтению на них.

Моя оценка

Скорость: 5 / 5. Это самый быстрый способ: всего неделя и первые деньги в кармане!

Достоверность: 2 / 5. Но не совсем достоверный. Ваше личное общение с людьми, идеальность обещаний и малый размер выборки сильно загрязняют эксперимент.

Краудфандинг и стартап

Краудфандинг — это институционализированная продажа обещаний. Здесь вы тоже рассказываете, обычно с помощью видео и текстового описания, что хотите сделать. Люди, которым нравится придуманный вами продукт, дают деньги, и только потом вы его делаете. Отличие в том, что происходит все на специальной платформе.

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

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

Мой опыт

В марте 2019 я задумал создать книжные марафоны на основе сервиса «Скорочтец» и попутно прокачать читалку. На этот раз решил попробовать краудфандинг. Подготовка заняла около трех недель: я активничал в соцсетях, создал видео и текст.

Вы можете посмотреть, что получилось. Длительность кампании составила 36 дней. И в итоге она не завершилась успехом: собрано лишь 9 500 рублей из запланированных 250 тысяч. Немногие спонсоры, которые поддержали проект, больше интересовались текущим продуктом. Так что я сделал вывод, что книжные марафоны не востребованы пользователями, и пока не буду их реализовывать. И это тоже результат: представьте, сколько времени и сил сэкономлено!  

А вот читалку я все же не удержался и прокачал.

Моя оценка

Скорость: 3 / 5. Не очень быстро: 2–4 недели на подготовку и месяц самой кампании по сбору средств.

Достоверность: 3 / 5. На мой взгляд, достоверность выше, чем у ручных продаж, из-за большего размера выборки. Но тут накладывается эффект благотворительности и упомянутая идеальность обещаний.

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

И у вас такое было? Тогда вам будет интересно.

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

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

О приоритизации

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

В каждой организации по-своему распределяются ресурсы. Бывают команды с общими — и ограниченными — ресурсами: несколько менеджеров могут задействовать в разработке одних дизайнеров, программистов, аналитиков. В таком случае начинается борьба за них: на общих митингах надо быстро и достоверно (на цифрах) обосновывать, почему именно твою фичу, а не коллеги, должны взять в будущий спринт.

О важном

Обычно у компании есть цель, к которой она глобально стремится, — а значит, все выполняемые задачи должны приближать к ее достижению. Цели могут быть долгосрочными — они описаны в стратегии, — и краткосрочными, которые изложены, например, в roadmap’е на несколько месяцев. Но не стоит забывать: на каком бы уровне цели ни находились, они всегда связаны друг с другом. И наши задачи всегда должны следовать вектору глобальной цели. Если это не так, задайте вопрос «почему?» и, предлагая гипотезу, обязательно сверьтесь с целью бизнеса.

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

Приоритизация задач в несколько шагов

Шаг 1

Сначала рассмотрим способ, который поможет отбросить ненужные гипотезы.

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

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

Потом приходит время для следующей, более глубокой приоритизации.

Шаг 2

Посмотрим, какие существуют инструменты приоритизации:

• RICE;
• ICE Score;
• Kano;
• WSJF;
• GIFT.

Разберем один из них — RICE. Это метод приоритизации гипотез по разработке фич. Расшифровка названия:

• Reach — охват;
• Impact — влияние;
• Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат;
• Effort — трудозатраты.

Чтобы получить оценку по RICE, необходимо следовать следующему алгоритму приоритизации.

(Reach*Impact*Confidence)/Effort=Score

Reach — показывает, сколько пользователей будут применять новую функциональность. Посмотреть это можно по системам веб-аналитики, по прошлому опыту или по конкурентам.

Например, представим, что вы ставите баннер в новом формате на главной странице сайта, посещаемость которой — 10 000 уникальных пользователей в месяц. Получается, именно столько людей увидят вашу фичу. Если вы взяли месячный период, то используйте его при рассмотрении всех гипотез. Учитывайте это и тогда, когда начнете считать Impact в денежном выражении.

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

Confidence — чтобы понять этот фактор, задайте себе вопрос: как быть уверенным в своих действиях? Правильно: подкрепить их.

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

Перечислим часто используемые и известные способы подкрепления:

• UX-исследования;
• опросы;
• интервью;
• наблюдения;
• MVP;
• A/B-тесты;
• сторонние исследования;
• аналитика;
• и другие пользовательские исследования.

Не нужно забывать, что помимо результатов качественных и количественных исследований есть более простые доводы, почему вашу фичу должны взять в работу. Среди них:

• собственные убеждения;
• мировые тренды;
• мнение команды, эксперта, руководителя;
• «все конкуренты делают это», «продукт не работает без этого».

Еще важные каналы информации:

• топ обращений в саппорт;
• топ запросов от сейлз-менеджеров;
• топ запросов от клиентов.

В итоге у нас сформировался перечень способов, как подкрепить гипотезу. Этот список с расставленными весами привел в удобный вид Itamar Gilad — продакт-менеджер Gmail и YouTube ☺. Рекомендую почитать его блог — https://itamargilad.com/.

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

Effort — оценивается либо в часах разработки, либо в story point — это не меняет сути. Всегда можно привести к одной шкале.

В целом это все. Теперь можно заносить данные в таблицу, фильтровать по наибольшему значению Score и брать в работу.

Пример таблицы Score

Для каждого из параметров необходимо задать свою шкалу баллов. Рассмотрим это на примере Reach. Предположим, самую маленькую фичу могут увидеть/использовать 100 K уникальных пользователей, а самую крутую — 1 000 K. Берем 10-балльную шкалу и переводим наши значения:

Из таблицы видно, что гипотеза 2 наиболее приоритетна, — ее и нужно брать в работу первой.

Все это нужно, чтобы:

• сфокусироваться на главных задачах;
• обеспечить прозрачность работы;
• мотивировать команду.

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

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

Многие воспринимают игру как противоположность обучению. Как мамы, которые жалуются, что их дети «не хотят учиться, а только сидят за компьютером». При этом чадо может и в Minecraft играть, и учиться кодить на Python. Но это ж игрушки, верно?

Специалисты в сфере онлайн-обучения уже заметили, что во время игры информация воспринимается и запоминается в несколько раз быстрее и эффективнее, чем во время «классических» уроков. Узнаем, почему так происходит.

Игровая психология в изучении языков

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

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

Чтобы запомнить текст песни, которая вам понравилась, будет вполне достаточно 3–4 прослушиваний.

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

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

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

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

2. Игры улучшают восприятие на слух

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

3. Игры упрощают восприятие грамматики

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

Грамматические конструкции, идиомы и интересные фразы, которые используют игровые персонажи, откладываются в памяти, даже если вы специально их не изучаете.

4. Вы полностью погружаетесь в языковую среду

Современные компьютерные игры поддерживают высокую вовлеченность игрока — так что вам обеспечено погружение в языковая среду.

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

5. Игры повышают мотивацию

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

По сути, вы совмещаете приятное с полезным: отдых за интересной игрой и полноценную прокачку английского.

6. Игры улучшают мышление, память, реакцию

С помощью игр вы можете улучшать мышление в целом. Вот несколько примеров:

• Чтобы продвигаться по сюжету многих игр в стиле RPG, нужно размышлять, выстраивать тактику и стратегию, анализировать информацию и в полной мере использовать ресурсы.
• Action-игры отлично тренируют логику, скорость реакции и принятия решений, а также умение признавать и исправлять ошибки.
• Квесты и игры на поиск предметов развивают логику и внимательность.

Компьютерные игры медленно, но уверенно развивают косвенные навыки, которые влияют на результативность обучения.

Выбираем жанр компьютерных игр для прокачки английского

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

Квесты Point-and-click

Что это? Игры на поиск предметов и взаимодействие с ними. Часто они отличаются простыми сюжетами в фантастических сеттингах и несложными заданиями.

Чем полезно? Вы изучаете лексику на конкретных примерах. Если на картинке нужно найти «Scissors», а вы не знаете, что это, — можно воспользоваться подсказкой, которая укажет на предмет. И станет ясно, что это ножницы.

Неизвестные слова рекомендуем записывать в словарик, чтобы потом повторять.

Стоит попробовать: «Нэнси Дрю», The Adventures of Sherlock Holmes, L.A. Noire, Syberia, Deponia.

RPG — ролевые игры

Что это? Вы играете роль персонажа, у которого своя история и возможности. В рамках сюжета вы исследуете окружающий мир, общаетесь с NPC (Non-Player Characters — неигровыми персонажами), выполняете квесты. У героя есть глобальная миссия или цель, к которой он идет на протяжении всей игры.

Чем полезно? Вы вступаете в контакт с окружающим миром. В ролевках нужно много общаться с персонажами, поэтому автоматически прокачивается навык чтения и восприятия на слух. Обычно история и устройство миров RPG подробно описаны, и разбираться в них очень интересно.

Стоит попробовать: The Witcher, Kingdom Come: Deliverance, The Elder Scrolls, Neverwinter Nights.

MMO — онлайн-игры

Что это? Мультиплеерные игры, в которых вы находитесь в одном мире с множеством реальных игроков. Бывают на любой вкус: от военных стрелялок до фэнтезийных сюжетов с эльфами и гномами.

Чем полезно? Общением с реальными игроками со всего мира. Регистрируйтесь на иностранном сервере, становитесь членом развитого клана или альянса — и переписывайтесь в чате или разговаривайте через микрофон. Отличный вариант, чтобы побороть стеснение и начать общаться на ранних этапах изучения языка.

Стоит попробовать: Lineage II, World of Warcraft, Archeage, Perfect World.

Action

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

Чем полезно? Экшн-игры учат воспринимать речь на слух. Для общего развития в плане языка они менее полезны, чем RPG или квесты. Зачастую диалоги нельзя приостановить, поэтому при уровне знаний Intermediate и ниже смысл будет ускользать. Но для разнообразия полезен и этот формат.

Стоит попробовать: GTA V, Far Cry, Call of Duty, Fallout, Assassins Creed, Dishonored, Mafia, BioShock.

Симуляторы жизни

Что это? Игра, в которой вы создаете персонажа и живете его жизнью. Это может быть кто угодно: от ученого-химика до стриптизерши. Можно выполнять квесты или просто веселиться, влипая в странные и смешные ситуации.

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

Стоит попробовать: Sims, Second Life.

Советы для прокачки английского с помощью компьютерных игр

1. Держите на смартфоне открытый словарь, чтобы смотреть значения слов и фраз, не отвлекаясь от игры.
2. Все новые выражения записывайте, чтобы повторять в дальнейшем. Узкоспециализированную и фэнтези-лексику можно фиксировать по вашему усмотрению.
3. Не переводите мысленно английскую речь на русский язык — старайтесь сразу воспринимать образы. Это ускорит понимание и даст толчок к активному развитию языка.
4. Выбирайте игры, которые вам нравятся. Не старайтесь играть через силу — вы не получите удовольствия, поэтому и английский не прокачаете.
5. Не стоит слишком увлекаться играми. Часа в день будет вполне достаточно, чтобы расслабиться и поработать над английским. Если играть дольше, результативность изучения новой лексики сильно упадет.

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

Учите английский с умом и используйте все инструменты, чтобы совершенствовать владение языком!

И, конечно, бонусы для читателей.

Хотите прокачивать английский самостоятельно?

Ловите промокод на 2 месяца премиум-подписки на онлайн-курсы от EnglishDom.

Готовы учить, но мешает график, нет времени на дорогу или не нашли «своего» преподавателя?

Как насчет индивидуального обучения с преподавателем мечты, за которым не нужно ехать на край света?

Записывайтесь на пробное занятие в EnglishDom — это бесплатно.

А по промокоду GB_read_skype — при первой оплате 2 урока в подарок.

Если вы учитесь платно, можете получить налоговый вычет. Так государство поддерживает тех, кто стремится к знаниям. Вопреки стереотипам, вычет не зависит от формы обучения, так что вернуть часть денег можно и за онлайн-образование. Важно, чтобы у учреждения, где вы грызете гранит науки, была лицензия, которая бы подтверждала его статус учебного заведения. (У GeekBrains такая лицензия, конечно, есть.)

Требования предъявляются не только к образовательной организации, но и к вам. Чтобы получить налоговый вычет, нужно быть резидентом РФ, иметь официальный доход и платить с него 13 % налога. Если получаете зарплату в конверте и НДФЛ не платите, возвращать вам просто нечего. Вычета также не положено безработным студентам, индивидуальным предпринимателям на упрощенке, ЕНВД или патенте или тем, кто платил за образование средствами материнского капитала.

Налоговый вычет можно получить за три прошедших года. То есть в 2019 году вы еще можете вернуть часть затрат на обучение в 2016.

Сколько денег вам вернут

Максимальная сумма социального вычета за собственное обучение равна 120 тысячам в год. Но не спешите потирать руки — это не значит, что вам вернут именно столько. Размер вычета определяет сумму, которая не будет облагаться НДФЛ. Со 120 тысяч вы заплатили бы 15 600 рублей. Их-то вам и вернут, если за год вы потратили на образование 120 тысяч рублей и больше.

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

Если вы учитесь не один год, лучше оплачивать образование поэтапно, чтобы получать налоговые вычеты ежегодно.

Рассказываем на примерах.

Пример № 1

Васе начисляют зарплату в 45 тысяч рублей в месяц, на руки он получает 39 150. За год он заплатил НДФЛ в сумме 70 200. Вася прошел курс повышения квалификации, который обошелся ему в 30 тысяч рублей. 13 % от 30 тысяч — это 3 900 рублей, их-то Васе и вернут.

Пример № 2

Петя студент, но в свободное время подрабатывает курьером. Его зарплата до вычета НДФЛ — 7 тысяч в месяц, с нее он заплатил за год 10 920 рублей. За обучение он отдал 120 тысяч, но получить сможет не 15 600, а только 10 920, так как государство возвращает налог, но не приплачивает.

Пример № 3

Олег — Васин коллега с аналогичной зарплатой. Он пошел на двухгодичные курсы переквалификации, чтобы сменить профессию. За них можно было платить по 70 тысяч за каждый год или 140 тысяч сразу. У Олега были деньги, и он решил полностью оплатить курс. Поэтому вычет составил лишь 15 600 — так как затраты превысили максимальную сумму. Если бы Олег платил за каждый курс отдельно, получил бы 18 200.

Как оформить налоговый вычет

Есть два пути оформления налогового вычета — в зависимости от того, как вы хотите получать деньги.

Через работодателя

Один из плюсов такого подхода в том, что вам не нужно дожидаться конца года, чтобы претендовать на возврат средств. Деньги от налогового вычета будут возвращаться вам по чуть-чуть каждый месяц. Бухгалтер перестанет удерживать с вас НДФЛ, пока вы не исчерпаете положенный вам лимит. Например:

Вася получает 45 тысяч рублей в месяц, бухгалтер ежемесячно удерживает 5 850 в счет НДФЛ. Вася потратил на учебу 140 тысяч, и ему положен максимальный вычет в 120 тысяч. В первые два месяца бухгалтер не будет удерживать налог с Васиной зарплаты целиком, и он будет получать по 45 тысяч. В третий месяц НДФЛ возьмут только с 15 тысяч (120 000 – 45 000 – 45 000), и Вася получит 43 050 рублей (30 000 + (15 000 – 13 %)).

Чтобы оформить налоговый вычет через работодателя, нужно предоставить ему письменное заявление об этом и уведомление от налоговой службы о вашем праве на вычет. Чтобы получить уведомление, придется предоставить в ФНС пакет документов:

• заявление на получение уведомления от налогового органа о праве на социальный вычет;
• копию договора с учебным учреждением на оказание образовательных услуг с указанными в нем реквизитами лицензии (или копии и договора, и лицензии);
• чеки, подтверждающие оплату обучения.

Когда вы принесете в бухгалтерию уведомление от налоговой, они все сделают сами, вам останется только получать деньги.

Через налоговую

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

• заполненная декларация 3-НДФЛ (сделать это можно на сайте ФНС);
• справка 2-НДФЛ о начисленных налогах (получить можно в бухгалтерии; если вы официально оформлены в нескольких организациях, справки придется получать в каждой из них);
• копия договора с учебным учреждением на оказание образовательных услуг с реквизитами лицензии (или копии и договора, и лицензии);
• чеки, подтверждающие оплату обучения;
• заявление на возврат НДФЛ в связи с расходами на обучение.

Документы можно подать через сайт ФНС в электронном виде. Это быстро и просто, но понадобится электронная подпись — ее можно оформить прямо на сайте. Для получения вычета декларацию 3-НДФЛ вы можете заполнить в любое время года, здесь ограничения со сроком до 1 апреля не действуют.

Можно также подождать, когда на сайт выгрузят справки 2-НДФЛ — обычно это происходит в середине года. В этом случае вам практически ничего не нужно будет заполнять: данные подтянутся в декларацию нажатием одной клавиши. Чеки и договор прикрепите в отсканированном виде.

Если сайт ФНС вас не устраивает, документы можно направить письмом по почте или отнести в отделение налоговой службы лично. У ФНС есть три месяца на проверку ваших документов. Если все в порядке, деньги вернут в течение месяца. Если что-то заполнено не так, вас уведомят, и придется устранить ошибки и вновь подать документы.