Русские документы
Ежедневные компьютерные новости RSS rusdoc.ru  Найти :
http://www.rusdoc.ru. Версия для печати.

10 советов заказчикам коммерческого ПО

Раздел: Programming / Управление проектами @ 18.01.2010 | Ключевые слова: управление проектами заказчику

Автор: mihteh
Источник: habrahabr

Давайте представим, что у вас есть беспроигрышная гениальная идея для программного продукта, в котором остро нуждается рынок, при этом и заказчик программного обеспечения (вы) и компания – аутсорсер, нанятая на проект — отличные ребята. Заказчик отличается адекватностью и порядочностью, а аутсорсер исполнительностью, ответственностью и профессионализмом. Почему же даже при таких условиях некоторые проекты с треском проваливаются? Рецепт краха состоит из многих ингредиентов, и в лучшем случае мы задумываемся о них только когда сталкиваемся с проблемой, а в худшем — истинная причина остаётся незамеченной и вина за провал валится, допустим, на кризис(тм).

Для заказчика идеальный вариант взаимодействия с аутсорсером — поставил задачу, подождал, получил готовый продукт, заплатил деньги. Но так не бывает. Никогда. Процесс разработки ПО связан с тесным взаимодействием заказчика и исполнителя на каждом этапе разработки, и от эффективности этого взаимодействия во многом и зависит успешность проекта. Наша компания занимается созданием насыщенных веб — интерфейсов, и хоть мы пока не являемся гигантом в этой области, уже накопили некоторый опыт и набили собственные шишки. Этой статьёй мы хотим помочь заказчикам ПО создавать качественные и прибыльные софтверные решения. Мы дадим вам 10 советов, следуя которым вы сможете организовать эффективное взаимодействие с вашими аутсорсерами и существенно сократить риск провала проекта.

1. Думайте о пользователях


Перед тем, как обратиться к аутсорсерам, вы должны знать ответы на следующие вопросы:
  • Кто будет вашими основными пользователями?
  • Как они думают, о чём мечтают, какие у них проблемы?
  • Как создаваемое ПО поможет им?

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

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

2.Описывайте проблему, а не решение


Не навязывайте исполнителям своё видение по реализации. Даже если кто-то сказал вам, что «Java — это круто», или что не существует нормальных СУБД, кроме Oracle. Ведь ваша задача — запустить на рынок успешный продукт, а не запустить на рынок успешный продукт, написанный на Java. Бывают ситуации, когда приложение нужно реализовать с помощью только этих технологий, и ни каких других, но в общем случае существует множество вариантов реализации, и эти варианты должны предлагать не вы, а аутсорсер, исходя из своих знаний, возможностей и видения ситуации. Доверяйте профессионалам!

Это всё равно, что вызывать электрика на дом — вы звоните человеку, которого считаете компетентным в этой области, жалуетесь ему, что у вас часто вырубается свет в квартире, он приезжает со своими инструментами, разбирается в проблеме, предлагает несколько вариантов решения. Первый вариант, допустим, замена проводки с увеличением сечения кабеля, замена автомата и добавление дополнительных электрических групп, что влечёт за собой капитальный ремонт жилья, а другой – просто замена автомата на более мощный, намного менее затратное решение, но при этом вы рискуете выходом из строя проводки, что в лучшем случае повлечёт за собой возвращение к первому варианту. Решение по реализации принимать вам, исходя из вашего видения, финансовых возможностей и желания сделать на века или обойтись малой кровью. Когда вы звоните мастеру, вы же не говорите ему «Захвати пассатижи и перфоратор», даже если сами разбираетесь в электросетях.

3. Осторожно относитесь к технологиям


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

Пусть исполнитель убедится в возможности использовать ту или иную технологию, может быть настройки вашего сервера не позволяют внедрять Yii, или стоит отказаться от Google Gears в пользу HTML5 т.к. приложение разрабатывается для iPhone, в котором нет поддержки Gears, но есть Safari, в котором есть HTML5. Сюрпризы несовместимости, преподнесённые в разгаре разработки, могут похоронить ваши нервные клетки и бюджет. Если продукт будет удобным и востребованным, никто не скажет «Фууууу, они написали на Delphi!», но если приложение будет сложным в инсталляции, если оно будет накладывать множество ограничений на ПО пользователя или будет требовать установку дополнительных фреймворков\модулей\плагинов, пользователи отвернутся от вас, а конкуренты будут смаковать ваше поражение.

4. Чётко формулируйте задачи


При постановке задачи ориентируйтесь на то, что вы лучше разбираетесь в предметной области, чем исполнитель. Вы скорее всего связаны со сферой деятельности, для которой пишется данное ПО. Как минимум, если у вас возникла задача написать именно такую программу, вы (хочется думать) разобрались почему возникла такая потребность.

Вам всегда нужно помнить — вы наняли не телепатов. В цепочке моёПониманиеЗадачи → реализацияЗадачи

существуют промежуточные звенья. Вот они:

моёПониманиеЗадачи → какЯОбъяснилЗадачу → какИсполнительПонялЗадачу → реализацияЗадачи

При общении с программистами забудьте паттерн «это само собой разумеется». Чаще он всплывает не при постановке задачи, а уже при тестировании\отладке проекта, когда выясняется, что те или иные функции программы не были реализованы или были реализованы не так, как нужно, т.к. они не были прописаны в ТЗ, ведь это само собой разумеющиеся элементарные истины. Поэтому лучше потратить лишние 30 минут на постановку задачи, чем лишние 6 часов на постановку костылей при сдаче проекта. Запомните — то, чего нет в ТЗ не обязано быть и в конечном продукте, а если оно есть, то разработчик реализует это исходя из собственного видения, которое в 99 случаев из 100 отличается от вашего.

5. ТЗ и договор — Ваши лучшие друзья


Типовое ТЗ — первый признак провала. Если исполнитель прислал вам типовое ТЗ для вашего проекта (а ТЗ в общем случае должен писать исполнитель), это значит он не вник в суть задачи, и скорее всего не захотел вникать. Если вы сами прислали ТЗ на оценку, и компания–аутсорсер не внесла в него ни каких изменений — насторожитесь. Если исполнитель после постановки задачи не засыпал вас вопросами — бегите.

Если вы не прочитали внимательно договор — готовьтесь к неприятностям.
В договоре чётко должны быть прописаны следующие моменты:
  • права и обязанности сторон;
  • сроки и обязательства;
  • порядок выплат;
  • штрафные санкции для обеих сторон.

К договору обязательно должно быть приложено ТЗ, согласованное и подписанное обеими сторонами.

6. Коммуникация — половина успеха


Опишем основные средства связи и ситуации, при которых их следует применять:
  • e-mail: утверждение ТЗ, утверждение договора, постановка глобальных задач, корректировка планов;
  • личная встреча: обсуждение задачи, сдача проекта;
  • бумажная почта: бумажный документооборот;
  • мессенджеры: оперативное оповещение, приглашение в скайп;
  • скайп: обсуждение рабочих моментов;
  • системы багтрэкинга: учёт багов и мониторинг процесса их устранения.

Мы не утверждаем, что заказчик обязан быть всегда на связи и в своих проектах вовлекаем клиента ровно настолько, насколько он хочет быть вовлечён (мы не рассматриваем вариант неадекватного заказчика, все наши клиенты – чудесные милые люди). Но чем оперативней заказчик отвечает на вопросы аутсорсеров, чем больше вдумывается в задачу и чем лучше взаимодействует с исполнителями, тем качественней получается продукт.

7. Не бойтесь удалённых исполнителей


Мы находимся в Краснодаре, при этом наше местоположение абсолютно не мешает нам выполнять проекты для заказчиков из Москвы, Иркутска, Санкт-Петербурга, Филадельфии и многих других городов. При общении с аутсорсером из другого города или даже страны, самое главное — договор и предоплата. Для заказчика плюс иногородних исполнителей заключается в том, что можно сделать дешевле без потери качества ( хотя в провинции стоимость программиста в 2-3 раза меньше, чем в Москве, было бы ошибкой думать, что провинциальные программисты не так профессиональны, как столичные). Для аутсорсеров плюс в том, что можно работать с заказчиками, находящимися в любой стране Мира, и не привязываться к географическому положению их офиса.
Есть и свои минусы:
  • различия часовых поясов;
  • языковой барьер;
  • различное законодательство;
  • задержка при передаче документов.

Если исполнитель находится в вашей стране и в вашем часовом поясе, актуальной остаётся только последняя проблема.

8. Используйте итеративный подход и отчуждаемые этапы


Существует много методологий разработки ПО: waterfall model (модель водопада), spiral model (спиральная модель), Extreme Programming (XP), Rational Unified Process (RUP), Microsoft Solutions Framework (MSF) и другие. Не будем заострять внимание на каждой методологии, скажем только, что наш совет противоречит некоторым из них.

Если проект относительно небольшой и если вы почти уверены, что ТЗ не будет меняться в процессе разработки, тогда разделите задачу на максимально отчуждаемые этапы (модель водопада). Если говорить о разработке веб-приложения, то отчуждаемые этапы могут быть такими:
  • написание ТЗ;
  • разработка дизайн-макетов;
  • HTML вёрстка;
  • программирование;
  • тестирование и инсталляция;
  • поддержка.

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

Если проект большой, и вы пока сами не знаете насколько, но начинать его реализацию нужно прямо сейчас, тогда разбейте его на отчуждаемые итерации, окончание каждой из которых будет связано с выпуском очередной версии продукта (спиральная модель). Первоначально сконцентрируйтесь на жизненно важном функционале, затем реализуйте запланированные «плюшки», опираясь на первые отзывы клиентов, затем запустите третью итерацию и сделайте приложение ещё лучше. И так до тех пор, пока ваш продукт не станет идеальным. Плюс данного подхода в большей гибкости процесса разработки, минус в возрастающей по сравнению с предыдущим подходом сложности смены исполнителя. Так что настраивайтесь на долгую и тёплую дружбу с вашим аутсорсером.

9. Разделяйте wishlist и buglist


«Доработка» — обычно самый стрессовый этап для аутсорсера. За нашу практику не было ещё ни одного случая, когда в ходе реализации проекта клиент не вносил бы изменений в задачу. Примерно 70% этих изменений носит чисто косметический характер и их реализация требует от 10 минут до нескольких часов. Бывают и такие пожелания клиента, реализация которых требует от одного до нескольких дней, и в общем случае почти все эти пожелания не выходят за рамки ТЗ и могут даже не выходить за рамки утверждённых дизайн-макетов.

По нашему опыту, реализация пожеланий клиента занимает 5-30% от всего объёма работ. Как вы думаете, ваш аутсорсер заложил эти издержки в стоимость при подписании договора? Скорее всего нет, ведь вы обратились за помощью к команде программистов, а не к гадалке. Они просто не могут заранее знать сколько ваших пожеланий им придётся выполнить (особенно если это ваш первый совместный проект), так что скорее всего, если ваши пожелания укладываются в некоторую окрестность терпимости исполнителя, они будут выполнены бесплатно.

Вы можете сказать «Вот и отлично! Пусть выполняют за просто так!», но мы должны предостеречь вас от такой позиции, и вот почему:
  • если вы планируете и дальше работать с этими ребятами, скорее всего в оценку стоимости следующего проекта они включат реализацию пожеланий клиента, и скорее всего оценка будущих пожеланий будет произведена с большим запасом;
  • если схема выполнения дополнительных работ не оговорена заранее, будьте готовы к тому, что аутсорсер попытается изменить правила игры по ходу проекта (если проект большой), либо откажется от сотрудничества с вами после сдачи проекта, повесив на вас ярлык «проблемный клиент»;
  • возможно компания-аутсорсер будучи исполнительной и ответственной (как мы и договорились в начале статьи) молча и терпеливо выполнит ваши пожелания, но с каждым пожеланием негатив, накопленный к вам, будет расти. Негатив к заказчику — очень опасное явление, которое может иметь самые непредсказуемые последствия, от отказа выполнять дальнейшие пожелания, до отказа от проекта и возврата предоплаты прямо перед сдачей продукта. Вам ведь не нужны сюрпризы, правда?
  • вы можете слишком увлечься тягой к перфекционизму и забыть вашу конечную цель — запуск проекта. Вы можете не заметить, как в процессе доведения продукта до совершенства вы сорвёте все сроки, конкуренты выпустят менее функциональное, но более дешёвое решение, и ваш продукт станет ни кому не нужным ещё до запуска.

Мы можем предложить довольно простой выход — завести wishlist, в который записывать все пожелания, возникающие в ходе выполнения проекта. Когда основная часть работ будет выполнена, вы сможете оценить, успеваете ли вы реализовать эти «плюшки», либо их лучше заложить в следующую версию продукта, либо выполнить только основные. Аутсорсеру будет легко оценить объём дополнительных работ по проекту, и уверяю вас, вы станете самым любимым их клиентом.

Нужно, однако, отметить, что в отличие от wishlist, вы должны тщательно следить за выполнением пунктов в buglist. Все пункты баглиста, на 100% должны быть сделаны, и ни о каких дополнительных работах, форс-мажорах и отсрочках не может идти речи. Если аутсорсер не увидел каких-то подводных камней перед подписанием ТЗ — это его проблемы, если аутсорсер недооценил сложность работы и сжатость сроков — это его проблемы, если аутсорсер взялся за проект, который ему не под силу — это его проблемы. Тут ваша проблема только в том, что вы наняли исполнителей, которые не могут справиться с задачей. Запомните, 99% всех технических сложностей можно решить, найти альтернативный способ или обходной путь.

10. Планируйте риски


Думайте о том, как действовать, не если возникнут неприятности, а когда возникнут неприятности. Основные по нашему мнению риски, возникающие при разработке коммерческого ПО:
1. Срыв сроков.
2. Смена исполнителя.
3. Критические ошибки в приложении.
4. Отсутствие жизненно необходимого функционала.
5. Отсутствие спроса на продукт.

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

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

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

Отсутствие жизненно необходимого функционала вам уже практически не грозит, так как вы защитили себя от срыва сроков, разработка разбита на модули и приоритеты расставлены.

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

Кросспост с нашего блога.

Вернуться в раздел: Programming / Управление проектами
© Copyright 1998-2012 Александр Томов. All rights reserved.