Кто, например, запретил AliExpress-у попросить людей улучшить качество переводов? Многие из нас помнят тексты на aliexpress - «Слона рука пластырь много» или «рукоделие DIY алмаз живопись вышивка крестом швейные иглы алмазная вышивка красная роза 3d». Кому-то это надоело, и этот кто-то предложил пользователям «а поможем-ка али перевести тексты».
Не скажу, что уже всё хорошо.
Благодаря краудсорсингу в «СберБанке» (http://www.sberbank.ru/ru/s_m_business/crowds) появились приветливые девушки-консультанты,способные выдержать любой агрессивный натиск пенсионерок, и электронные очереди, и столик для детских рисунков. (!да-да, парни, прошу оставить за рамками нашего разговора вопрос о процентных ставках, не об этом сейчас речь). К сожалению, банк в своём развитии остановился. И внутри он остался с теми «непонятками», с которыми он был всегда.
Это вот несколько примеров краудсортинга.
Но с этими примерами ясно. Речь в них идёт по поводу исправления нескольких ошибок или предложения банку. Сами предлагающие ничего или почти ничего делать не будут. А что, если попробовать задействовать толпу людей, чтобы разработать конфигурацию?
Предположу, что можно. Однако следует сразу обговорить ограничения.
1. В классическом краудсорсинге деньги людям не платятся. Максимум, на что может рассчитывать инициатор, это получить скидку или ценный подарок - деньги на связь или планшет. Однако, например, такую видимость подхода разрушает компания «Витология», знаменитый апологет краудсорсинга (см., например, https://www.youtube.com/watch?v=yBCXjFBR1jE). В разрезе организации,например, это возможность социального лифта для сотрудников. Очень рекомендую посмотреть видео руководителя и основателя компании Александра Малюкова.
Будем говорить прямо - все мы работаем за деньги. В разработку 1С подавляющее большинство людей приходит для того, чтобы не только развиваться, но и заработать на жизнь. Понятно, что даже если будет привлечён человек со стороны для разработки конфигурации, то он должен быть обязательно мотивирован. Для чего? Для того, что
а) мотивированный человек будет поддерживать свою разработку и
б)мотивированный человек всё же выполнит работу на совесть.
Поэтому я вижу крауд-разработку как некий венчурный проект. Только «инвесторами» проекта выступают разработчиками (а инвестициями - разработки). Получить прибыль потом, позже, если сделано тобою всё правильно. Здесь, как говорится, занимайся, чем тебе хочется, хорошо занимайся, а деньги обязательно придут. Конечно же, отдача должна быть адекватной, «согласно купленным билетам».
2. Направленность выбора задач должна быть не на охват всего, что можно. Здесь, думаю, в помощь вот - https://habrahabr.ru/company/1c/blog/277237/. Несколько сумбурно, но в ней показывано, что приоритеты всё же должны расставляться правильно.
В то же время разработка обязана быть направлена под дальнейшее масштабирование. Сделанный учёт по товарам должен быть в расширяем и может быть основой для бухгалтерского учёта, к нему можно прикрепить аналитическую систему и прочее (примеры учёта взяты с потолка, не считайте руководством к действию).
Всё это подразумевает, что руководитель проекта должен стать Сталиным (прошу также оставить политические вопросы при себе - однако замечу, что экономическим гением Сталина лично я восхищаюсь). То есть нужны:
- предельная критичность при отборе задач. В свете вышеперечисленного - думаю, лучше не брать задачу в разработку, чем сделать её плохо;
- контроль и оценка сроков выполнения с самым большим вниманием. Обязательный контроль разработки, например, методом ежедневных отчётов с указанием выполненных этапов;
- налаживание координации работников в проекте. Например, разработчик не может не общаться со своими коллегами, если его разработка затрагивает разработки коллег;
- контроль доработок;
- отслеживание продаж и рекламы.
- и прочее (о чём вы можете сами указать в комментариях и, надеюсь, обязательно это сделаете).
В то же время именно такой подход позволит привлечь для решения любое количество независимых разработчиков для одной задачи. И в результате этого выбрать оптимальное решение (а, главное, долгосрочное решение).
3. Разработчики не только обязаны придерживаться стандартов. Считаю, что и сами стандарты нужно ужесточить. Например, ограничить процедуры и функции 30-ю строками кода (это только моё личное предположение по количеству строк). Или, например, обязательное ознакомление с уже имеющейся разработкой, чтобы не дублировать код. Любой шаг вправо или влево от правил карается расстрелом не приветствуется.
4. Работы каждого разработчика должны проверяться. И, думаю, не одним человеком, а несколькими. Да, по тем самым стандартам. Да, по совместимости с разработками других людей. И не должно бысть страшно что-нибудь переделать, если найдётся ошибка или будет предложено более оптимальное решение.
Список, думаю, можно продолжать.
Я, например, считаю отрицательным примером разработки ОС Linux (прошу... ну вы поняли меня). Что бы ни говорили её фанаты. Массово разработанная операционка имеет массу версий с кучей проблем. И - о чудо какое происходит - когда разработка Linux становится не-краудсорсинговой - Mac или Android или серверные версии от Oracle - её качество становится заметно лучше.
Считаю, что это беда не того, что руку к ней приложили тысячи людей. Твёрдо уверен, что это последствие того, что не было жёстких стандартов и выверки кода, не было и координации между разработчиками.
Я же предлагаю спроектировать и построить общими усилиями универсальный и очень работоспособный проект. Какой? Предлагайте...
А что делать с готовой конфигурацией? Дорабатывать, также краудсорсингом. И продавать. Всем вместе. Зарабатывать деньги. Это не менее важная, даже бы сказал более важная часть, чем разработка (вариант - я изобрёл лекарство, теперь нужно открыть болезнь для него - не пойдёт).
Жду ваших мнений.