Рассмотрим, какое отношение имеет совершенствование рабочих процессов к тому, что принято называть кризисом, и о чем мы неоднократно, в наших курсах, уже говорили. Кризис следует интерпретировать, как недопонимание, в том числе между разработчиком и заказчиком, между руководителем и подчиненным, поскольку, как мы помним при разработке программных систем существует достаточно много интересов и достаточно много разных точек зрения, для которых нужно найти компромиссы и построить верные оценки по срокам, стоимости и качеству тех результатов, которые мы ожидаем получить. Таким образом, следует способствовать верной оценке или уточнению, как можно более полному этой оценки для продукта или проекта, которые мы собираемся осуществить. При этом необходимо с точки зрения руководителя предоставить достаточно четкие, точные, недвусмысленные полные инструкции для подчиненных. Представить верные ограничения по процессам, с точки зрения ресурсов, сроков, стоимости, качества. Выделить самое главное, отбросив для начала второстепенные детали, особенно, когда мы говорим о верхнем уровне планирования и архитектурного проектирования, по возможности провести аналогии, дать метафоры, как мы помним в гибком подходе к разработке. Это достаточно важно, в том числе возможно с предыдущими проектами с предыдущими продуктами, с тем, что как говориться по предыдущим знаниям, это один из наших семи принципов разработчикам уже знакомо. Сообщить подопечным свои ожидания и ключевые показатели, выстроить правильные метрики, в том числе сказать не только, что вы ждете, как руководитель, но и чего вы не хотите увидеть в качестве результата. Ну и естественно проверить понимание задания, проекта и тех ожиданий, которые имеются. Таким образом, можно избежать кризиса недопонимания и обеспечить более высокую эффективность разработки, как на личном, так и на командном уровне, в том числе и для корпоративных систем, в том числе и в сложных кризисных условиях. Рассмотрим более подробно организацию навыков, оценки и планирования при производстве программного обеспечения. Прежде всего, небольшой пример, из жизни некоего Уоттса Хамфри, специалиста по процессам из компании IBM, из его ранних лет, когда он служил в военном флоте. Можно привести такой пример, они учились стрелять из автоматов по мишеням, которые представляли собой, как говорит Уоттс Хамфри, глиняных голубей. При этом именно у этого конкретного матроса, будем говорить, результаты получались не очень хорошие. Одного взгляда опытного инструктора было достаточно для того, что бы вынести вердикт и скорректировать процесс стрельбы. Вердикт был таким, стрелять нужно, прицеливаясь с другого глаза, не с того который сам матрос считал ведущим. При этом выясняется, что быстрый взгляд опытного инструктора, даже на внешние показатели результатов стрельбы, привел к тому, что соответствующая коррекция существенно повысила показатели эффективности стрельбы. О чем это говорит нам, с точки зрения нашего курса? О том, что нужно уделять существенное внимание оценке, анализу и планированию, при этом естественно и самооценке. Как мы видим, Уоттс Хамфри в этом примере недостаточно внимания уделял самооценке и коррекции процессов в связи с этим. Какие советы и рекомендации можно дать по разработке программных систем в этой связи. Прежде всего, необходимо, как можно быстрее, своевременно предоставлять отзывы о результатах и позитивную обратную связь, которая должна быть целевой и оперативной. Использовать стандартные метрики и ключевые показатели, которые сообщать разработчикам достаточно рано о том, что есть какие-то проблемы с проектом, о том, что имеет смысл, как-то корректировать процессы. Предоставить возможности для самооценки, сформировать понимание, что такое достаточно хороший продукт или программная система, для того чтобы у разработчиков не было ни завышенных, ни заниженных ожиданий и целевых показателей, а они, эти самые показатели, правильным с точки зрения проекта и ожидания от этого проекта, как для разработчика, так и для заказчика, образом, этот проект вели и продвигали к завершению. Ну и что касается планирования. Каким образом можно способствовать планированию на личном и командном уровне? Прежде всего, нужно добиться артикуляции детального плана, данного сверху, может быть руководителем программы или проекта, может быть заказчиком, может быть топ-менеджерами для того, что бы без искажений, ключевые показатели проекта были доведены до исполнителей. Затем, нужно убедиться в том, что все уровни проекта отвечают этому глобальному плану и мы существенно не выйдем за рамки тех ресурсов, которые необходимы, при производстве нашего программного продукта на каждой его стадии, будь то архитектурное проектирование, реализация и тестирование, интеграция и передача заказчику и так далее. Кроме того каждый разработчик должен быть в состоянии предложить и разработать, скорректировать, адаптировать, развить свой собственный план на основе глобального, который показывает каким именно образом он будет решать свои задачи в том случае если возникнут, какие-то существенные риски, в том случае если возникнет, скажем дефицит ресурсов и иные проблемы. Ну и наконец, планирование должно стать важной частью проекта и должно быть учтено в целевых показателях разработки.
