Психология инициативной разработки

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

Меня будут интересовать 4 типичные роли:

• пользователь-ламер
• продвинутый пользователь
• разработчик проприетарного ПО
• разработчик СПО

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

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

Теперь рассмотрим разработчика СПО.

При этом я хочу сконцентрироваться на разработках среднего уровня сложности, т.е.

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

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

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

Наша разработка - электронный классный журнал РУЖЭЛЬ - тоже попадает в разряд специфического ПО.

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

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

Хочу обратить внимание на возникновение в этот момент серьезного конфликта между двумя совершенно разными задачами:

• программистской, которая ставилась для одной конкретной ситуации
• маркетинговой, в которую превратилась исходная - распространение решения для других.

Стоит подчеркнуть, что программист, как правило, совсем не специалист в маркетинге.

Подвергнем этот конфликт анализу - рассмотрим несколько его аспектов.

1. Насколько полученное решение может быть полезно кому-то еще?
   1. Начальный замысел, который являлся ведущим мотивом деятельности разработчика, сменяется новым, который не предполагался в начале работы или, по крайней мере, не был ведущим.
   2. Даже если разработчик корректно и грамотно решил задачу, еще не факт, что такое решение нужно кому-то еще, по крайней мере, в такой комплектации: само программное решение и соответствующее программное окружение - dependencies.
   3. Кроме того, для распространения решения его нужно добротно документировать, а это для разработчика обычно очень сложная психологически проблема: ему проще сделать 3 разработки, чем одно описание-инструкцию.
   4. Для обеспечения многократного воспроизведения полученного решения в различных условиях необходимо подготовить всю совокупность составляющих решение элементов. Для широкого распространения начинаются вопросы:
   • насколько интересна эта задача другим
   • в чем ее преимущества / недостатки по отношению к аналогам
   • насколько просто развернуть весь комплект ПО
   • насколько удобен этот комплект
   • насколько гибко он учитывает различные сочетания технических и программных средств
   • насколько понятно описание
   • насколько подготовлена система поддержки
   • как донести эту информацию и убедить в своих преимуществах
2. Насколько адекватна логика разработки задаче распространения?
   1. В сфере проприетарного ПО маркетинговые вопросы решаются иначе: сразу с позиции потребителя, а не разработчика. Причем, часть вопросов из представленного выше списка отдельные специалисты решают еще до начала разработки, а остальные вопросы - параллельно с работой программиста. Коммерческие фирмы могут позволить себе не одного программиста, как часто бывает в инициативной разработке, а столько, сколько нужно для завершения работы к заранее запланированному моменту. К нему же независимо готовится благоприятная обстановка для распространения.
3. Есть ли у разработки перспективы развития?
   1. Разработчик СПО не уверен в судьбе своей разработки. Перспектива финансовой отдачи на затраченные усилия весьма неопределенная. Часто эта отдача заметно отстает от момента размещения готовой разработки в открытый доступ. Развитие разработки возможно только в том случае, если есть иной источник дохода, поэтому вероятность ее прекращения существенно выше, чем в случае проприетарного, которое умирает только в случае финансовых потрясений (банкротство, продажа).
   2. Можно ли что-то противопоставить в этих условиях проприетарным разработкам? Для СПО остается использовать те возможности, которыми не может располагать проприетарный разработчик,- инфраструктуру сообщества СПО. Но и тут не все просто. Сообщество СПО наиболее активно проявляется в распределенной среде разработки. Однако, творческих инициатив - фактически конкурирующих проектов - довольно много. В результате преимущество сообщества далеко не всегда удается реализовать.
4. Есть ли у разработки при наличии спроса адекватная техническая поддержка?
   1. Создавая решение конкретной задачи, разработчик имел в виду ту ситуацию, которая имеет место у исходного заказчика:
   • либо он предполагал себя самого работающим на техподдержке у заказчика
   • либо он предполагал существующую у заказчика техническую службу.
   1. При желании широко распространить свой продукт разработчик должен искать решение для массовой технической поддержки. Не будучи уверенным в большом спросе (сразу его никогда не бывает - он созревает постепенно), разработчик просто откладывает эту проблему до возникновения реального спроса. В результате, когда и если спрос возникнет, он окажется не готов.
   2. И здесь можно было бы попытаться использовать энтузиастов СПО по месту жительства для технической поддержки ламеров. Но, даже если есть продвинутые пользователи, которые готовы заняться такими услугами, организация их в надежную службу и доведение контактной информации до ламеров - тоже проблема маркетинга, только теперь в сфере услуг по поддержке СПО.
5. Готов ли разработчик обеспечить обучение по работе с распространяемым СПО?
   1. Для серьезного продукта обычно недостаточно инструкции по эксплуатации. Многие предпочитают обучение на курсах самостоятельному копанию в инструкциях, которые очень редко бывают понятными и удобными. Хотя для СПО это один из реальных источников дохода, сам разработчик далеко не всегда может грамотно обучить других своему творению - это уже педагогическая задача. Она имеет свою специфику и требует, как минимум, способности доходчиво объяснять, хотя лучше иметь профессиональные педагогические навыки.

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

Вывод

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

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

М. Э. Кушнир

13.01.2009