В последнее время в прессе всё чаще можно увидеть статьи, посвященные перспективам развития отечественного пограммирования в качестве отдельной индустрии. И все чаще особое внимание уделяется проблемам выхода российских производителей Программного Обеспечения на мировой рынок. Один из путей - выполнение аутсорсных проектов уже широко практикуется многими российскими компаниями.

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

Рассмотрим этот момент подробнее. Что такое качество? Качество - это способность товара или услуги наилучшим образом соответствовать ожиданиям потребителя. Именно в таком ключе понимание качества трактует стандарт ISO 9001. В нашем конкретном случае, под этим понятием разработчиками, как правило, подразумевается отсутствие ошибок в коде программ, ими написанных. На мой взгляд, это не так. Этот подход слишком односторонен и ни в коей мере не отражает всей глубины существующей проблемы. Более того, именно такой подход и служит восприятию заказчиками (особенно иностранными) наших разработчиков как производителей некачественного ПО. Из своего персонального опыта работы с нашими и зарубежными клиентами, я выделил для себя целый ряд негативных моментов, с которыми сталкиваются многие заказчики, начиная проект в России. Остановлюсь на некоторых из них:

Отсутствие понимания требований заказчика (не пользователя)
Прежде всего, это происходит от того, что стратегические цели и задачи, которые преследует исполнение проекта, изначально плохо сформулированы. В конечном итоге, это выражается в проблемах во взаимоотношениях с заказчиком при сдаче проекта, из-за плохопроработанных или отсутствующих совсем критериев приёмки (aceptance plan). Самая распространенная проблема наших разработчиков из этой области - неспособность уложиться в сроки выполнения проекта, так как реальные цели и задачи, стоящие перед исполнителями, выясняются лишь по ходу работы. Большинство незавершённых проектов становятся таковыми именно из-за этой проблемы.
Неудовлетворительная работа с клиентом
Также, из своего опыта, могу сказать, что далеко не все заказчики являются компетентными в области ИТ-технологий. И самые большие проблемы в этом плане возникают при подписании документов о завершении какого-либо промежуточного этапа работ. Далеко не все заказчики способны разобраться в современных нотациях, таких как UML или IDEF0, представляемых им нашими программистами, поэтому они требуют представления материалов в виде текстовых описаний. Но даже самые подробные текстовые описания в некоторых случаях вызывают полное непонимание у заказчика из-за низкой технической грамотности. "Мы не будем это подписывать, потому что не понимаем, что вы нам представили" - вот вполне вероятное заявление заказчика, если с самого начала не озаботиться тем, чтобы готовить всю документацию на понятном для него уровне восприятия. Причины этого, на мой взгляд, кроются в пренебрежительном подходе к низкой технической компетентности заказчика и нежелание разработчиков помогать клиентам в приобретении новых технических знаний.
Низкий уровень подготовки аналитиков и прожект-менеджеров
Проблема, думаю, очевидна и о ней тоже неоднократно упоминалось в СМИ. Как правило, разработку модели для какого-либо конкретного бизнеса в маленьких компаниях проводят сами программисты. При этом, воспринимая свою задачу лишь как техническое решение, исходя из Технического Задания. О самом бизнесе, для которого и делается проект, а тем более о специфике этого бизнеса, программист имеет лишь очень отдалённое представление. Я уже не говорю о том, что заказчик может быть иностранцем и его бизнес может сильно отличаться от такого же бизнеса, но в российских реалиях. Тем более, что даже само представление об удобстве использования ПО может сильно различаться, если сравнивать будут российский программист и западный бизнесмен.
Как правило, изучение предметной области каждого вида бизнеса занимает 5-6 лет института, плюс 3-4 года опыта работы для того чтобы полностью разобраться в специфике, а решения для этого бизнеса, призванные его оптимизировать в рамках проекта, предлагаются инженером-программистом никогда в этом бизнесе не участвовавшем. В этом случае вряд ли заказчику следует ожидать полного понимания своих проблем со стороны разработчиков. В то же время, для любого специалиста, изначально не знакомого разработкой ПО, изучение бизнес-нотации, применимой в ИТ-сфере, занимает всего 1-2 года. Эта проблема легко бы решалась, если бы разработкой самой бизнес-модели ПО занимались люди, хорошо знакомые с этим бизнесом. Изначально, в этом случае, разговор с заказчиком вёлся бы на принятой в его бизнесе терминологии и сбор требований проходил бы более качественно, а ожидаемый эффект от использования такого ПО был бы максимальным.
Некачественное отношение к пректированию пользовательских интерфейсов
Эта проблема, в свою очередь, декомпозируется на несколько других проблем:
- Пренебрежение услугами профессиональных дизайнеров и проектировщиков интерфейсов, способных разработать дизайн и цветовую гамму, соответствующую ожиданиям потенциального потребителя. Мне приходилось видеть отечественные разработки с совершенно классной математической бизнес-логикой и функциональностью, но снабженные совершенно убогим, я бы даже сказал, отталкивающим интерфейсом. Причем, пожелания потенциальных заказчиков изменить интерфейс, воспринимались разработчиками даже несколько агрессивно.
- Непонимание проблемы удобства пользователей. Программист, безусловно, хорошо владеющий компьютерной терминологией и всеми принципами работы с компьютером, изначально настроен так, что пользоваться его программой будут такие же опытные пользователи-потребители. В реальности же, естесственно, дело обстоит по-другому и жалобы от пользователей на эргономичность и неудобство того или иного интерфейса можно слышать постоянно. Опять же, совершенно непонятно из каких соображений это следует, но менеджеры проектов очень часто выступают на стороне программистов.
- Игнорирование "тупого" пользователя (fool safe) . На Западе, любая уважающая себя компания, стремящаяся занять на рынке свою нишу, в обязательном порядке разрабатывает и вводит в свои программные продукты, так называемую, "защиту от дурака", когда неопытному пользователю просто не оставляют возможности потерять плоды своей работы в ходе неумелых действий. И чем выше такая защита - тем выше маркетинговые возможности продукта и оценка его самим потребителем. Наши же разработчики практически не уделяют никакого внимания этой проблеме.
- Перманентное стремление внести "своё" разнообразие, которое приводит к тому, что для выполнения схожих действий создаются "уникальные" интерфейсы. В конечном итоге, продукт теряет своё единообразие для использования, теряет некий "стиль", что, в свою очередь, не может не сказаться на его оценку потребителем.
- Текстовые ошибки, опечатки и общая небрежность в оформлении. Опять же, это происходит потому, что программист фокусирует своё внимание исключительно на решении логической или технической задачи. И такая простая мысль о том, что написанное с ошибкой слово или смазанная картинка вызовут у пользователя раздражение - не приходит ему в голову! Между тем, пользователь, как правило, весьма раздражённо реагирует на подобные дефекты интерфейса и воспринимает их исключительно как неуважение к себе.
- Отход от общепринятых и широко распространенных канонов, привычных для пользователя По-моему, совершенно очевидно, что гораздо легче работать с той программой, интерфейс которой (общий дизайн, иконки, логика и т.д.) похожа на тот, с которым работаешь постоянно, например MS Windows. И, уж, совершенно непонятно из каких соображений, наши разработчики начинают реализовывать свои собственные представления об этом в ПО, производимом, например, для массового пользователя. Желание воспроизвести "нечто особенное" может запросто обернуться нежеланием пользователя купить эту программу, если он сочтёт её трудной для освоения и дальнейшей эксплуатации.
Низкое качество отчуждения продукта (deployment)
Это одна из "маркетинговых" проблем. Как правило, очень немногие российские разработчики озабочены удобством дальнейшего использования своих продуктов. Например, отсутствие инсталляционных пакетов делает неудобным для заказчика процесс внедрения разработанной по его заказу программы. Более того, требует привлечения дорогостоящих специалистов для специальной настройки, а иногда и для дальнейшей поддержки.
Очень слабой, на мой взгляд, стороной является и сопровождение программного продукта сопутствующей документацией, прежде всего, ориентированной на конечного потребителя. Различного рода хелпы и руководства очень часто сложны для понимания пользователя и недостаточно отражают все возможности использования продукта, потому что пишутся, как правило, самими программистами.
А такое простое решение как разработка тренинг-курса, призванное помочь пользователю эффективнее осваивать продукт, даже не принимается в расчет. Естесственно, маркетинговые возможности от этого не выигрывают. К очевидному проигрышу в маркетинге можно отнести и слабое развитие в российских компаниях полноценных служб он-лайн поддержки пользователей с отдельными (не говоря уже о бесплатных) телефонными линиями и штатом специально обученных сотрудников.
Плохая работа sales & marketing
Это уже стало, своего рода, "притчей во-языцех". Наряду со всем известными проблемами, таких как: недостаточный опыт в развитии дилерской сети, недостаточная квалификация и слабое понимание бизнес-этики персоналом, слабое знакомство с современными методиками продаж, хочется выделить непонимание самого понятия "продажа" между разработчиком и заказчиком в аутсорсных проектах. Очень часто наши разработчики стремятся предоставить заказчику само решение, как конечный продукт, при этом забывая его уведомить о том, во что выльется последнему доработка и внедрение этого решения. Тут дело даже не столько в анализе стоимости проекта и метода продажи решения, сколько в отсутствии самой практики изначально готовить клиентов к выделению дополнительных ресурсов в дальнейшем. К сожалению, подобный подход к работе нередко оставляет крайне негативное впечатление у заказчика, что и порождает негативное отношение к российским разработчикам в целом.
Отсутствие знаний и опыта по закрытию проектов
Ни для кого не секрет, что каждый успешно реализованный проект - это плюс в портфолио компании. Но мало кто идет дальше того, чтобы указать этот проект на своём сайте только в этом качестве. Между тем, на Западе совершенно объективно существуют традиции использовать опыт работы с одним и тем же заказчиком по нескольку раз. Маркетинговые методики и разработка рабочих инструкций по действиям после завершения проекта позволяют неоднократно получать заказы с одного и того же клиента. В качестве примеров можно привести простые напоминания о себе (прежде всего о положительном опыте сотрудничества), поздравления с праздниками, совместный promotion и т.д.
В России же, очень часто можно видеть, как общение разработчика с заказчиком заканчивается сразу же по окончанию проекта. Тем самым упускаются дополнительные возможности по развитию бизнеса.
Одним из самых характерных недостатков следует назвать отсутствие полноценного мониторинга потребительских (пользовательских) отзывов после закрытия проектов и прекращение дальнейшего тестирования. Вместо того, чтобы предупреждать возможное появление недовольства качеством продукта, наши разработчики, в лучшем случае, собирают и анализируют уже появившиеся жалобы на качество своих разработок. Сюда же можно отнести и отсутствие опыта по организации полноценной службы технической поддержки с персоналом, ориентированным исключительно на решение проблем пользователя.
Отсутствие или слабая квалификация профессиональных тестировщиков в проекте
Вся суть проблемы заключается в том, что в России только-только начала формироваться индустрия производства Программного Обеспечения и началось настоящее разделение труда. Еще пару лет назад о такой профессии, как тестировщик, мало кто слышал, и уж тем более, о том, что в отрасли тестирования ПО уже несколько лет существуют свои стандарты и методики. Поэтому в сознании российских программистов прочно утвердилось мнение о своей способности самостоятельно тестировать свои разработки, изначально воспринимая под понятием "качество" лишь правильность написанного кода.
Из-за того, что становление профессии "тестировщик ПО" находится на самом начальном этапе, появление методик по подготовке профессиональных тестировщиков тоже запоздало. Особенно это заметно при сравнении с американской или европейской индустрией. Поэтому умение создавать столь необходимую для каждого серьёзного проекта документацию, как тест-план - присуще далеко не каждому тестировщику. Эта проблема перекликается с другой важнейшей проблемой - проблемой низкого качества ведения самого проекта. До сих пор, во многих компаниях, прожект менеджеры привлекают тестировщиков лишь на конечных стадиях проекта, поручая лишь выполнить тестирование интерфейса и общего функционала. При этом происходит отход от методологии самого тестирования и не происходит накопления тестовой документации, столь необходимой для работы тестировщиков при последующем развитии проекта. К сожалению, до сих пор встречаются даже такие компании, которые не производят учет ошибок, обнаруженных при тестировании.
К области недостатков в тестировании обязательно следует отнести еще одну немаловажную проблему - прожект менеджеры очень часто не выделяют для тестирования необходимые ресурсы и не обеспечивают наличие в команде опытных тестировщиков-профессионалов, способных самостоятельно ставить задачи по тестированию. Часто приходится слышать о том, что задачи на тестирование ставятся самими программистами. О каком качестве российских разработок, в этом случае, можно тогда говорить? Особенно, по сравнению с западными, где в компаниях-разработчиках, помимо "штатного" профессионального, уже давно разработаны процедуры бетта-тестирования, с целью привлечения максимального количества независимых пользователей к испытаниям своих разработок. Естесственно, в любом проекте, для подобных испытаний отдельно выделяется и время, и финансы, и человеческий ресурс.

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

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

На рынок труда приходят всё новые специалисты, уже изначально ориентированные на выпуск качественного ПО, и спрос на них всё возрастает. И это не может не радовать...

Дизайн и поддержка: Silicon Taiga

Обратиться по техническим вопросам