Первый урок по программированию (конечно же, FORTRAN) я посетил, когда учился в колледже в 1970. За последние же полвека я провёл уйму времени, работая с ПО, а именно за разработкой требований, проектированием, программированием, тестированием, управлением проектами, написанием документации, управлением развитием процессов, выпустил 7 книг и множество статей, а также консультировал и обучал.
Естественно, на протяжении всего этого пути были и сторонние занятия вроде получения степени кандидата химических наук и нескольких лет работы в качестве учёного-разработчика. Но всё же в большей степени я был занят именно работой с ПО.
За всё это время я осознал и выработал бесчисленное множество концепций в сфере программного бизнеса. В этой статье я предлагаю вам 64 постулатов, многие из которых будут наверняка вам интересны и полезны.
О требованиях
- Если вы как следует не подготовите требования, то как бы хорошо не была выполнена вами остальная часть проекта, вы его провалите.
- Бесчисленные заметки на доске, сохранённые письма, голосовые сообщения и полузабытые разговоры в коридоре не формируют требования, а являются лишь кучей информации.
- Интересы участников проекта максимально пересекаются именно в процессе выработки требований продукта.
- Не сформировав качественных требований, учредители могут получить продукт с сюрпризами. А сюрпризы в сфере ПО почти всегда являются плохими новостями.
- Выявляя требования, думайте не только о непосредственных пользователях, т.к. даже после удаления клиент всё равно остаётся вашим клиентом.
- Люди не просто “собирают” требования. Формирование требований — это процесс исследования, сотрудничества и изобретения, а не просто сбор информации. Бизнес аналитик — это не просто писарь.
- Цель определения требований в том, чтобы максимально точно передать послание пользователя разработчику. Бизнес аналитик в данном случае стремится сократить коммуникационную дистанцию между ними.
- Самые распространённые методы формирования требований на основе телепатии и ясновидения не работают.
- Несмотря на то, что твердит нам наша культура, клиент прав не всегда. Однако у него всегда есть собственная позиция, которую вы должны понимать и уважать.
- Разработка требований не производится в один этап. Вы не сможете правильно сформировать их набор сразу после первого обсуждения. Честно говоря, вы скорее всего никогда не сможете сформировать их точно. Эффективная разработка требований подразумевает нарастающее уточнение деталей и ясности.
- Не стоит бояться документирования требований. Цена записи знания весьма невелика в сравнении с ценой его обретения.
- Если какая-либо возможность или характеристика не описана в требованиях, то и в итоговом продукте её ожидать вовсе не стоит.
- В результате разработки появляется не просто набор писаных требований, но также общее понимание и представление об ожидаемом продукте.
- В реалистичной форме разработка требований ведёт не к созданию совершенного набора требований, а к созданию требований, которые будут достаточно хороши, чтобы позволить команде разработчиков продолжать работать на приемлемом уровнем риска. Этот риск заключается в реализации чрезмерных, незапланированных переделок из-за упущенных, ненужных, незавершённых, двусмысленных или плохо согласованных требований.
- Иногда мы выражаем требования обыденно, поскольку предполагаем, что читатель обладает схожей с нашей восприимчивостью. Однако люди зачастую интерпретируют одни и те же утверждения по-разному. Такая неоднозначность ведёт к несоответствию ожиданиям и сюрпризам в итоговом продукте.
- Сохраняйте небольшим круг людей, разрабатывающих требования и производящих ревью. Большая группа не сможет договориться даже об эвакуации из горящей комнаты, не говоря уже о единогласном утверждении какого-либо требования.
- Первым вопросом человеку, предлагающему какое-либо требование, должен быть такой: “Входит ли оно в рамки проекта?” Если ответ “Да.”, тогда оно должно быть рассмотрено. Если же нет, то не должно, по крайне мере на данный момент. В случае, когда ответ “Нет, но оно должно быть включено”, вам стоит перестроить область проекта, чтобы это требование в него входило. При этом учтите, что всё это сказывается на затратах, графике реализации, ресурсах, обязательствах, приоритетах и компромиссах.
- Если у вас нет задокументированной и согласованной области проекта, то как вы сможете понять, что выходите за её рамки?
- Принимая решения о включении тех или иных функций в продукт или в список для рассмотрения, избегайте “расстановки приоритетов по децибелам”. Самые громкие клиенты не обязательно требуют максимально необходимый функционал с точки зрения бизнеса.
- Участники проекта должны понимать разницу между обсуждением возможного требования и обязательством включить его в продукт.
- Ваша кровь должна холодеть, когда вы слышите выражения подобные следующим: “Предполагаемые требования” и “Подразумеваемые требования”. Стремитесь к открытому обсуждению ожидаемого.
Об управлении проектом
- Управление проектом не существует в обособленной форме. Управление проектом — это смесь управления людьми, требованиями, рисками, возможностями, ожиданиями, обязательствами, изменениями, ресурсами и снабжением.
- Почему у организаций вечно не хватает времени на изначально грамотную продуманную разработку ПО, хотя они всегда находят и время, и деньги, и людей, чтобы исправлять его после? Эта тайна до сих пор не разгадана.
- Всем нравится считать, что их команда обладает исключительным талантом, но половина всех разработчиков ПО имеют навыки ниже среднего уровня. А где, по вашему мнению, работают все эти люди?
- Никому не сообщайте предварительные прогнозы. Лучшим ответом на запрос о прогнозировании будет: “Мне нужно всё обдумать, и я смогу сообщить вам ответ позже.”
- Независимо от давления со стороны других, никогда не давайте обязательств, которые не сможете выполнить.
- Вы находитесь в более выгодной переговорной позиции, когда имеете данные для обоснования вашего дела, потому что у другого, скорее всего, вообще не будет никаких данных.
- Пока вы не начнёте записывать ваши прогнозы и сравнивать их с происходящим в действительности, вы будете всегда только гадать, но не прогнозировать.
- Прогноз, сообщаемый вами кому-то, не должен искажаться тем, что, как вам кажется, от вас хотят услышать.
- Менеджер проекта должен обладать гибкостью в как минимум одном из пяти ключевых направлений: область проекта, график, персонал, бюджет и качество. Если все они будут представлены в ограниченной форме, вы потерпите неудачу.
О качестве и улучшении рабочего процесса
- Когда дело касается качества ПО, то вы можете либо заплатить сейчас, либо заплатить существенно больше в последствии.
- Стремитесь к идеалу, довольствуйтесь совершенством.
- Никогда не позволяйте боссу или клиенту уговорить вас делать плохую работу.
- Качество должно быть вашим высшим приоритетом. Продолжительная продуктивность является естественным следствием высокого качества, поскольку командам не приходится тратить кучу времени на доработку и исправления.
- Старайтесь, чтобы дефекты обнаруживали коллеги, а не клиенты. Технические ревью со стороны коллег являются доказанным методом повышения качества и продуктивности.
- Ни одна техника разработки ПО не сработает, если вы будете иметь дело с нерассудительными людьми.
- Когда человека просят работать каким-то иным способом, их естественная реакция спросить: “А мне то оно зачем?” Но этот вопрос некорректен. Верным будет спросить: “А зачем это нам?”
- Люди, работающие с ПО, постоянно ищут крутые инструменты, но стоит помнить, что дурак с инструментом — это просто усиленный дурак.
- Тяжело убедить людей в необходимости изменения рабочего процесса, когда они не осознают всю ущербность текущего. Сложно продавать улучшенную модель мышеловки тем, кто не в курсе, что у них водятся мыши.
- В: Сколько лидеров процесса разработки требуется для замены электрической лампы?
О: Всего один, но лампочка должна желать замены. - Не стоит недооценивать необходимость и сложность изменения культуры организации по мере внедрения новых способов работы. Установка новых способов существенно быстрее, чем смена культуры, вам же нужно, чтобы и то, и то завершилось успехом.
- Несмотря на благие намерения, бесполезно планировать действия по улучшению, если действия в итоге не предпринимаются.
- Здравый смысл, правильное суждение и опыт во многих случаях должны превосходить формальность рабочего процесса. Хотя иногда эта формальность вполне обоснована. Поэтому прежде, чем её обойти, выясните, насколько это так.
- При направлении организации к новым способам работы, используйте мягкое, но постоянное воздействие.
- Лучшая мотивация для смены методов работы людьми — это боль. Не искусственная, причинённая извне боль, но реальная, ощущаемая командой, в связи с текущим методом работы. Выбирайте такие действия по улучшению, которые максимально снизят её проявления.
- Пока вы не начнёте выделять время на рассмотрения прошлого опыта, изучение пройденных уроков и продолжительное совершенствование командного процесса, нет смысла ожидать от следующего проекта лучших результатов, чем от предыдущего.
- Вы не сможете изменить всё разом. Определите те изменения процесса, которые принесут лучшие выгоды и начните реализовывать их уже со следующего понедельника. Я не шучу — именно со следующего понедельника!
- Примените философский метод “уменьшить, чтобы подошло” к шаблонам документации. Начните с насыщенного шаблона, напоминающего вам о той информации, которая, вероятно, должна быть включена, а затем подстраивайте его под размер, суть и нужды каждого проекта.
- От многих команд просят сделать больше из меньшего, хотя при этом очень часто эти команды не снабжаются необходимыми средствами для получения этого “большего из меньшего”. Не обеспечивая тренировки и улучшения процесса для повышения эффективности и результативности, можете не ожидать магического прироста продуктивности.
- Неформальные процессы, которые отлично работают для четырёх людей в одной комнате, не масштабируются на несколько команд разработчиков, работающих на разных континентах.
- Если выделить одну единственную вещь, в которой индустрия разработки ПО постоянно повторяется, то ей будет совершение одних и тех же глупостей в каждом последующем проекте. Используйте ретроспективный анализ для постоянного обучения, понимания и совершенствования.
- Каждый раз, когда люди не следуют установленному рабочему процессу, у вас есть всего три выбора: 1) начать следовать ему; 2) перестроить процесс для повышения его эффективности и практичности, а затем начать следовать ему; 3) исключить этот процесс и перестать притворяться, что вы ему следуете.
Дополнительные утверждения
- Искусственный интеллект не способен заместить реальный.
- В мире технологий, если вы на неделю опережаете другого, то уже считаетесь волшебником.
- Сегодняшняя разработка под лозунгом “Нужно сделать как можно скорее” — это завтрашний кошмар в обслуживании устаревшей системы.
- Многие проблемы систем ПО возникают в интерфейсах: ПО-к-ПО, ПО-к-аппаратному обеспечению, ПО-к-людям, люди-к-людям. Изучайте их внимательно.
- Люди много говорят о своих “правах”. Но у каждого права есть своя оборотная “обязанность”. Размышляйте и действуйте сообща.
- Грамм проектирования стоит килограмм рефакторинга.
- Остерегайтесь управления по журналу “Businessweek”, т.е. спешки создать горячую новинку в ПО только потому, что кто-то прочитал о её многообещающих результатах.
- Держите ваш большой и указательный палец на расстоянии пары сантиметров друг от друга. В большинстве случаев это расстояние и есть то единственное, что отделяет качественный проект от мусора. А речь здесь идёт о необходимости больше слушать, проверять свою работу, повторно выполнять тесты, сверяться с контрольным списком, читать директивы, задавать на один вопрос несколько других. Зачастую это всё, что нужно для сохранения этого расстояния.
- У вас нет времени на совершение каждой ошибки, допущенной каждым разработчиком ПО до вас. Читайте и исследуйте литературу, учитесь у коллег, безвозмездно делитесь своими знаниями с другими.
- Разработка ПО, вероятнее всего, на 50% состоит из вычислений и на 50% из обмена информацией. А вот бизнес аналитика состоит исключительно из обмена информацией. Мы же гораздо лучше справляемся именно по части вычислений.
- Если вы позиционируете себя как независимого консультанта или наёмного работника, то должны проинформировать мир о своей доступности. Не важно насколько вы хороши, если никто о вас не узнает.
- Мы очень много притворяемся в мире ПО. Мы делаем вид, что определили верных участников проекта, что они понимают свои бизнес-задачи и знают требования. Мы делаем вид, что правильные люди сообщили нам верные требования, а мы правильно их поняли и записали. Мы делаем вид, что наши расчёты точны и, что мы продумали все необходимые задачи. Мы делаем вид, что никакой из возможных рисков не подорвёт внезапно наш проект. Я не большой поклонник притворяться, т.к. хоть я и не всегда без ума от реальности, но она — это всё, что у меня есть, поэтому приходится иметь дело именно с ней. Давайте прекратим притворяться.
Читайте также:
- Как преодолеть синдром самозванца: 6 советов разработчикам
- О чём не говорят инженеры ПО
- 4 шага для повышения концентрации
Перевод статьи Karl Wiegers: 64 Lessons from 50 Years of Software Experience.
