Пользовательские истории. Искусство гибкой разработки ПО (Паттон) - страница 139

Исследования, опубликованные организацией Standish Croup в отчетах Chaos прошлых лет, доказывают, что от 64 до 75 % функциональностей используются редко или не используются никогда[27]. А 75–90 % всех IT-стартапов (в зависимости от того, что считать неудачей) не достигают успеха[28].

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

В старые недобрые времена я, как правило, работал примерно так. Я приносил очередную блестящую идею, или, честно признаюсь, то, что было мне предложено генеральным директором или важным заказчиком как их блестящая идея. Я дорабатывал ее, конкретизировал, корректировал. Затем я и моя команда приступали к реализации. Разработка всегда занимала вдвое больше времени, чем мы ожидали, но об этой проблеме мы поговорим в следующих главах. Мы заканчивали. Мы представляли сделанное клиентам. Мы устраивали вечеринку. Иногда вечеринка предшествовала представлению продукта. Но в любом случае в конце концов все было сделано.

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

Но, к счастью, есть способы работы получше.

Несколько лет назад со мной связался один клиент и спросил, могу ли я помочь адаптировать процесс, который он назвал мышлением дизайнера. В организации этого клиента был внедрен процесс, типичный для Agile, и дела у них шли неплохо – неплохо в том смысле, что все предъявлялось вовремя и с хорошим качеством. Но, как известно, чем быстрее предъявляешь барахло, тем больше барахла получаешь. Это, конечно, звучит грубовато. Другими словами, клиент убедился, что корреляция между количеством программного обеспечения, которое они разрабатывали, и эффектом, который получали в результате, была невелика.

В то время я был известен как специалист по дизайну пользовательского взаимодействия и разработке Agile. Я подумал: «Раз я дизайнер и способен мыслить, значит, у меня есть мышление дизайнера». Но я был не прав. Это было не то, что имел в виду клиент. К счастью, я не высказал свою мысль вслух.