Авторы: Алексей Янчук, Константин Кондратюк

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

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

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

— (Я) Так то оно так, но не совсем. В первую очередь мы должны поставлять заказчику решение его проблем.

— (Коллега) Ну, так а я что сказал? Мы должны устранять все возможные баги. Чем больше, тем лучше, верно?

— (Я) Конечно, устранение багов – это движение в нужном направлении. Только вот устранение багов не является самоцелью. Не факт, что продукт без багов решит проблемы клиента.

— (Коллега) Слушай, проблемы не у нас, а у наших хостеров. У них возникли непредвиденные задержки. Наша группа-то причем тут?

— (Я) Как тебе сказать… Ваша группа вобщем-то причем. Ваш продукт не в эксплуатации. Мы не можем поставить бенефиты нашим клиентам. С нашей точки зрения, вы задерживаете релиз.

— (Коллега) Да, но ведь это проблема у хостеров, а не у нас!

— (Я) Да хоть проблемы у электрической компании – конечным пользователям что с этого? Продукт не выпущен.

— (Коллега) Как не выпущен! Мы все сделали! Мы же тестировали все компоненты по отдельности! И они работают!

По итогам разговора каждый, увы, остался при своем мнении.

Начнем с простого: с понимания, когда продукт работоспособен?

Работоспособный продукт удовлетворяет всем требованиям, заявленным заказчиком, с учетом принятых им (под подпись) особенностей и ограничений. Если же продукт не вписывается в этот критерий – он неработоспособный. Все ли пукты соглашения об уровне обслуживания (SLA) выполняется? Если не выполняется хотя-бы один, не критичный и важный пункт, – SLA не выполняется. Точка.

Помнится, много лет назад мы никак не могли понять эту черно-белую логику. Вот же софт – результат нашего проекта, он работает. Он же не падает! Он делает все, что вы просили. Да, он вот тут чуть-чуть подтормаживает и не дотягивает до нужного перфоманса… Но ведь ваши требования были такими запутанными, а не дотягивает он же совсем чуть-чуть!.. Почему же вы говорите, что софт не работает?.. Он же работает! Смотрите, вот тут такой юз-кейс прошел!

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

Так и получается, что к тому моменту как программист более-менее набирается опыта, у него формируется сугубо программистское представление о том, что из себя представляет ИТ-деятельность. Представим, что наш программист 10 лет писал классы, делал билды, организовывал тесты, моделировал, и т.п. А потом он попадает в реальный мир – туда, где принимаются решения. От него ожидается, что он внесет вклад в принятия решений, а он только и думает о классах, билдах, и как качественно все будет протестировано последними-распоследними тулзами.

На пальцах это можно объяснить на следующей аналогии. Круглая ли планета Земля? Смотря откуда смотреть. Если смотреть с высоты человеческого роста она будет казаться плоской. Если посмотреть с высоты 560 км. – она будет шаром. Получается, что (кажущееся) плоское может одновременно быть круглым. Приблизительно тоже справедливо при сравнении проектов с продуктами: с точки зрения проекта мы делаем что-то плоское, с точки зрения заказчика мы хотим получить что-то круглое. Парадокс?

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