Если разработчик во время очередного митинга уже не в первый раз слышит от возмущенного заказчика просьбу с надеждой, чтобы ничего не сломалось, то возможно пришло время взглянуть на проект шире. В таких случаях было бы логичным поднять вопрос о замене разработчика либо выяснить причины таких ситуаций, но на деле зачастую все иначе.
Поэтому может создаться впечатление, что вместо заказчика проектом руководит разработчик. Как будто клиент зависит от него и при этом оплачивает разработку. Получается ситуация со спутанными ролями или же «Клиент в Зазеркалье».
Почему так выходит и как это можно исправить? Ну что ж, давайте разбираться.
«Надеюсь на этот раз, ничего не сломается»
Ситуация, когда клиент продолжает возлагать свои ожидания на разработчика несмотря на возникающие казусы, как правило происходит по следующим причинам:
- Возможно, специалист обладает уникальными знаниями или навыками, которые трудно заменить, и заказчик вынужден мириться с его ошибками;
- Или же на проекте отсутствует документация, что делает задачу сложной для понимания всеми участниками проекта.
По классике проектного управления, в этих случаях был бы проведен анализ текущего состояния проекта для выявления основных проблем. Также был бы произведен пересмотр процессов разработки, улучшена или составлена отсутствующая документация, проведены дополнительные тренинги для команды. Полезным было бы и обсудить с заказчиком ожидания и требования, чтобы убедиться, что все стороны понимают цели и задачи проекта.
Если же проблемы продолжаются, несмотря на все перечисленные усилия, тогда действительно был бы поднят вопрос о смене конкретного специалиста или даже всей команды разработчиков. В конечном итоге, успешный проект требует слаженной работы всех участников и взаимного понимания и доверия. Если этого нет, то любые усилия напрасны.
Но на деле, жертвой экономии ресурсов, становится проектная документация. К сожалению, можно легко попасть в такое «Зазеркалье» если сэкономить на бизнес требованиях продукта, которая может быть представлена в виде Объема работ (Scope of Work), Спецификации требований программного обеспечения (Software Requirements Specification, или SRS), а также Спецификации (известные, как Спек или SPEC).
Без должного внимания к этим документам, возрастают шансы, что проект столкнется с множеством проблем, таких как недопонимание между всеми участниками, пропущенные сроки и превышение бюджета. Поэтому давайте разберемся насколько ценны такие документы и насколько важно их наличие на проекте.
Рекомендуем прочитать План реализации проекта (PEP) и План управления проектом (PMP): Какой из них вам нужен и почему стоит выбрать оба?
Документация ценности не имеет, или все не так, как кажется на первый взгляд?
Первое время, как правило до первых релизов продукта, документация ценности не имеет. Она забирает время и ресурсы на свое сопровождение, а надо скорее делать новые фичи и запускать продукт – нет времени на ведение документации. В дальнейшем все чаще и чаще возникают ситуации при которых изменение исходного кода продукта в одном месте приводит к появлению багов в другом.
Это приводит к тому, что команда начинает тратить больше времени на исправление ошибок и устранение неполадок, чем на разработку новых функций. В таких условиях становится очевидно, что отсутствие документации значительно замедляет процесс веб-разработки и ухудшает качество продукта. Когда же проект достигает определенного уровня сложности, документация и вовсе становится незаменимым инструментом.
Давайте рассмотрим несколько ситуаций, чтобы лучше понимать ценность документации.
Ситуация №1. Нужно изменить компонент ПО, но нигде не зафиксировано, как он работает
Предположим, что несколько раз компонент корректировали, но это было настолько давно, что сложно вспомнить детали. Разработчик исследует код приложения и пытается понять как указанная фича должна работать. Без документации ему приходится тратить много времени на изучение кода в попытках понять, как все работает.
Как итог, на основе своих личных выводов он и начинает дорабатывать этот компонент. После проведения Smoke-тестирования (также известное, как Дымовое тестирование), разработчик отдает проделанную работу клиенту на проверку и подтверждение. Не зная всех тонкостей, заказчик бегло видит, что все работает, как он просил, и поэтому подтверждает публикацию изменений. При этом ни разработчик, ни сам клиент не ожидают возникновения каких-либо ошибок или что внесенные изменения затронут другие связанные с этим компонентом фичи.
Но из-за отсутствия документации, понимания о взаимодействии компонентов продукта и интеграционного тестирования возникает баг. Как итог, о подобного рода ошибках получится узнать только от пользователей, когда те их заметят и сообщат.
Недостатки:
Отсутствие документации замедляет процесс разработки и увеличивает вероятность ошибок.
Ситуация №2. Пользователь продукта сообщил о баге, который просит исправить
Рассмотрим пример, когда пользователь продукта обнаружил ошибку в работе программы и сообщил об этом через систему поддержки. Получив уведомление о баге и проанализировал его, клиент ставит задачу разработчику, чтобы тот устранил выявленную проблему и улучшил работу продукта.
Анализ может привести к следующим выводам:
- Поведение системы является адекватным
Разработчик начинает изучать исходный код и выясняет, что такое поведение системы, о котором сообщил пользователь, известно и ожидаемо. В коде находится комментарий, объясняющий, почему система работает именно так.
Однако, жалобу пользователя игнорировать нельзя, так как это повлияет на его удовлетворенность продуктом. В этом случае разработчик и заказчик решают зафиксировать найденную «ошибку» как улучшение. Это означает, что поведение системы будет изменено в будущем, чтобы лучше соответствовать ожиданиям пользователей.
Таким образом, клиент и разработчик оказываются в ситуации, описанной в первом примере, где необходимо внести изменения в компонент ПО, не имея полной документации.
- Баг подтверждается
Разработчик начинает изучать код и обращается за помощью к коллегам, которые знакомы с особенностями работы интересующего компонента ПО. Проводятся митинги, на которых обсуждаются возможные причины и способы исправления возникшей ошибки.
В итоге баг признается, и разработчик приступает к его исправлению. Однако, без полной документации, процесс исправления затрудняется, так как изменения в одном месте вызывают непредвиденные проблемы в других частях системы. Таким образом, команда снова приходит к Ситуации №1, где внесенные изменения способны затронуть другие связанные компоненты, что требует дополнительного тестирования и проверки.
Недостатки:
Без полной документации, процесс исправления и/или улучшения затрудняется и требует дополнительных проверок и обсуждений.
Ситуация №3. Увеличилось количество юзеров и нужна оптимизация
Представим, что приложением стало пользоваться больше юзеров и возросла нагрузка на продукт. Команда решает проанализировать текущую производительности системы и внести архитектурные изменения для поддержки дальнейшего роста количества пользователей. Однако, никто не помнит всех деталей реализации этой фичи, так как документация отсутствует или устарела.
Без нужной документации о компоненте не получится учесть всех особенностей ПО. Таким образом, из-за ее отсутствия процесс тестирования после архитектурных изменений выходит неполным. Как итог, некоторые баги останутся на этапе релиза изменений, которые также могут повлиять как на работу приложения так и его производительность.
Недостатки:
Без документации процесс оптимизации ПО становится более сложным и рискованным, так как разработчики не имеют полной картины того, как работает система.
Что важно знать заказчику
Не имея документации, достоверного источника информации обо всем продукте, описывающем все в целом и каждую фичу в отдельности, заказчик и команда проекта вынуждены опираться на свою память, а также на исходный код продукта. А поскольку исходный код ПО понимает только разработчик, то только он способен рассказать как именно работает продукт. Поэтому именно данный специалист становится тем, от кого в первую очередь зависит продукт, удовлетворенность пользователей и благополучие клиента. Заказчик же становится зависим от разработчика, создающего все эти баги, из-за которых появляется недовольство у пользователей и самого клиента.
Один из самых ошибочных шагов, который иногда совершают заказчики, оказавшись в подобной ситуации – это замена разработчика. У клиента может создаться впечатление, что текущий специалист не обладает нужным уровнем знаний о продукте или потерял прежний энтузиазм, а значит у другого профессионала получится изменить ПО к лучшему и с меньшим количеством ошибок. Такое решение значительно усугубляет ситуацию.
Если текущий разработчик обладал частичными знаниями о проекте и знаком с работой компонентов программного обеспечения, то новому специалисту потребуется время, чтобы познать его тонкости. Он будет опираться только на то, что видит на текущий момент в исходном коде продукта.
В таком случае, новому специалисту придется потратить несколько месяцев на изучение кода и столкнуться с новыми багами, пока он не достигнет того же уровня знаний о продукте, которым обладал предыдущий разработчик. Пока заказчик будет в это время терпеливо ждать дня, когда новый специалист познает все особенности продукта, он может потерять пользователей и деньги.
Чем дольше живет продукт, тем он требовательнее к документации.
Важно понять, что отсутствие качественной документации может не только усугубить текущую проблему, но и создать новые. Документация — это неотъемлемая часть всего процесса разработки и поддержания продукта. Она помогает избежать возможных проблем, обеспечивая ясность и понимание всех аспектов проекта, что в конечном итоге приводит к более стабильному и качественному продукту.
Когда требования и процессы не задокументированы должным образом, это создает зависимость от отдельных членов команды и приводит к серьезным рискам для проекта. Поэтому документация должна быть доступной и регулярно обновляться.
В заключение
Документация ценности не имеет, она бесценна. Она часть всего процесса и способна обеспечить долгую жизнь вашему продукту. Без качественной документации, инвестирование существенной суммы в разработку продукта, проведение дорогостоящей рекламной кампании и захват часть рынка могут не дать желаемого результата из-за затяжной разработки новых фич продукта и вносимых исправлений. Не изменяя отношение к документации, вы теряете лояльность пользователей и подвергаете проект значительному риску.
Если на вашем текущем проекте, реализуемом без документации, вам знакомы приведенные выше ситуации, вы с ними сталкиваетесь, возможно еще не поздно приступить к созданию документации?
Свяжитесь с нами, и мы будем рады разработать желаемый продукт с учетом создания необходимой документации для последующих успешных изменений и улучшений вашего продукта.
