Цитаты из книг автора «Алексей Минкевич»

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

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

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

Scrum — это фреймворк, предназначенный для разработки, поставки и поддержки сложных продуктов. Он хорошо работает в среде высокой неопределенности и подразумевает создание продукта или нового функционала в жестко фиксированные по времени и непродолжительные итерации — спринты (sprints). Итог каждого спринта — предоставление конечному пользователю работающего ПО с новыми возможностями. Scrum не является процессом, техникой или исчерпывающим методом. Напротив, Scrum — это фреймворк, в котором можно использовать разнообразные процессы и методы. Основные элементы фреймворка — scrum-команды и связанные с ними роли, события, артефакты и правила. Каждый элемент фреймворка служит определенной цели и является обязательным для успешного использования Scrum. Правила Scrum связывают вместе события, роли и артефакты, регулируют отношения и взаимодействия между ними. Scrum использует итеративный и инкрементальный подход, чтобы улучшать прогнозируемость и управлять рисками. Scrum основан на трех китах: прозрачности, инспекции и адаптации.

Основные принципы Agile отражены в специальном манифесте, который был принят в феврале 2001 г. Agile Manifesto содержит четыре основные идеи и 12 принципов[3]. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения. Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри нее. Работающий продукт — основной показатель прогресса. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. Простота — искусство минимизации лишней работы — крайне необходима. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Как видите, почти во всем принципы Agile полностью соответствуют тому, чему нас учит и классическая методология: вовлекать заказчика; частые результаты поставки лучше крупных разовых; самое важное — команда и ее мотивация. Обо всем этом мы уже говорили на страницах нашей книги. Давайте еще больше углубимся и посмотрим детальнее на Scrum, Kanban, XP и Lean.

Люди и взаимодействие между ними важнее процессов и инструментов. Каждая команда уникальна и может выстраивать процессы под себя. Процессы и инструменты вторичны, потому что только помогают закрепить высокий уровень, которого достигла команда. Если в какой-то момент команда понимает, что может стать еще эффективнее, делая что-то по-другому, она меняет процессы соответствующим образом. Работающий продукт важнее исчерпывающей документации. Нет смысла тратить время на описание продукта наперед, если вы только начали работать — планы могут несколько раз поменяться. Время на описание можно потратить более эффективно, сделав что-то для более быстрой разработки. Иными словами, зачем вам эксплуатационное руководство на автомобиль, разработка которого еще в процессе? Сотрудничество с заказчиком важнее следования условиям договора. Важно вовлекать заказчика в разработку, проактивно решать возможные вопросы и делать то, что нужно сейчас, а не то, что было нужно когда-то, при составлении договора. Готовность к изменениям важнее следования изначальному плану. Этот пункт следует из предыдущего. Условия меняются постоянно, современный бизнес развивается и адаптируется к новым требованиям очень быстро. Поэтому нужно быть готовым к изменениям в изначальном плане и принимать их не просто как должное, а с радостью. До работы по гибким методологиям нужно дорасти. Они лучше работают в зрелых, состоявшихся, ответственных командах, в которых люди понимают, чем они заняты, и стремятся к общей цели. Очень важно не путать Agile и бардак: часто бывает так, что в условиях полного хаоса и отсутствия управления люди уверены, что работают по гибким методологиям. Agile — это целое семейство практик, которые можно разделить на две группы: инженерные и процессные. К процессным относятся Scrum, Kanban, Scaled Agile Framework. Их задача состоит в том, чтобы организовать рабочий процесс и управлять им. Инженерные — это, например, Lean или Extreme Programming. Они используются инженерами для организации своей работы.

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

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

3. Чистая приведенная стоимость (Net Present Value, NPV). В этой модели мы учитываем прибыльность того или иного проекта с учетом влияния инфляции. При помощи формулы денежного потока можно рассчитать, сколько принесет проект в пересчете на его сегодняшнюю стоимость, ведь ценность 100-долларовой банкноты каждый год падает. Простой пример: допустим, годовая инфляция составляет 10%, а проект через год принесет $100. Какой будет ценность этой сотни для компании? $91. Почему? Именно такой будет покупательная способность сегодняшней сотни долларов через год. Расчет приведенной стоимости производится по формуле: Обратите внимание, что проценты накладываются. Если проект принесет $100 через два года, то при годовой инфляции в 10% эта прибыль будет равняться нынешним $83. И если сейчас положить на депозит $83 под 10% годовых (или инвестировать их в любой другой инструмент с такой же доходностью), то через год на счету компании будет $91, а через два — вся сотня. Как это знание помогает бизнесу в оценке проектов? Рассмотрим проект (табл. 5). Допустим, компании нужно в ближайшие два года инвестировать в реализацию проекта $300 000. Ожидаемая прибыль должна составлять $450 000. На первый взгляд, проект хороший! А теперь давайте посчитаем с учетом инфляции. Для простоты расчета допустим, что годовой уровень инфляции составляет 10%. Итак, в первый год нам нужно инвестировать $200 000. Кроме этого, еще $91 000 нам нужно положить на депозит, чтобы через год, когда подойдет время вкладывать деньги в следующую фазу проекта, их стало $100 000. Таким образом, приведенные затраты проекта составят $200 000 + $91 000 = $291 000. То же самое делаем с прибылью. В первый год проект принес $0. Во второй — $50 000, которые из-за инфляции превратились в $45 000. Считаем: $100 000 на второй год — это $83 000 в сегодняшних ценах. Наша ожидаемая прибыль через три года — $300 000, что в фактических сегодняшних ценах составляет всего $225 000. Итоговая приведенная прибыль — это $45 000 + $83 000 + $225 000 = $353 000. Фактически прибыль от реализации проекта составит не запланированные $150 000, а всего $62 000. Остальное «съела» инфляция. Это очень хороший метод расчета для долгосрочных проектов, который часто используется бизнесом. Кстати, из этого пункта можно сделать интересный вывод: если знакомый просит у вас в долг $10 000 на три года, то дать их ему без процентов — это преступление. Давать деньги в долг без процентов можно только близким друзьям, четко осознавая, что тем самым вы оказываете им непосредственную финансовую помощь.

2. Прибыль на инвестиции (Return on Investments, ROI). В этом случае мы рассчитываем, насколько выгодно нам вкладывать деньги в новый проект. Считать необходимо по формуле: Например, мы хотим заказать разработку продукта стоимостью $1,25 млн, а затем продать его за $1,5 млн. Как узнать, какую прибыль мы получим от инвестиции в этот проект? Подставляем данные в формулу: Получаем коэффициент 0,2, то есть наша прибыль составит 20%. Для работы с этой формулой важно знать следующее: если итоговый коэффициент больше нуля, то проект прибыльный, если меньше — убыточный; 0 — компания в плане денег ничего не теряет, но и не зарабатывает. Если говорить о времени, то здесь ситуация двоякая: время может быть потрачено зря, а может быть получен хороший опыт.