Я попробую рассказать о том, что большинство людей в этот момент забывают. Не важно, что они собираются разработать — библиотеку для обрезки картинок, фреймворк, сложнейший плагин для САПРа или очередную уютную ERP-CRM. Подумай, остановись. Погугли еще раз, пожалуйста. Возможно, не стоит даже начинать.
Пример, который знаком большинству программистов:
Несколько лет назад я пришел работать программистом в маленькую компанию. Мне собрали компьютер и техдир позвал к себе. Позвал знакомить с НИМ. Это был фреймворк, написанный на PHP 3-4 версий. Там было прекрасно все — и хранение исполняемого кода в БД, и админка на самодельном бутстрапе из таблиц, и базы с именами "__123123". Кстати, YII 1 в тот момент уже набирал обороты, а Django начал матереть. Нам было все равно мы были заняты планами по портированию своей внутренней разработки на ООП PHP. Ну, когда-нибудь. Когда будет лишний ресурс. То есть, никогда. А пока клиенты ждут, нужно начать на этом фреймворке еще 5 проектов. Мы уже подписали ТЗ.
Думаю, каждый программист сталкивался с этим явлением за свою карьеру. Мы с иронией вспоминаем свою наивность и списываем все на неопытность. Однако, причины совсем не в этом. Мы и сейчас делаем точно так же. Постоянно. Мы рождаем мамонтов, которые заведомо, исходя из своего плана развития, должны умереть. И их кости будут лежать прямо у нас в офисе. Где-то в проходе, чтобы спотыкались люди. Но это же наши корпоративные кости. Мы их, в принципе, сами сюда принесли и думали в этот момент головой.
Рождение
Вернемся к нашему озаренному сотруднику. Он откатился на стуле от компьютера и решил писать ПО. Не знаю, наверное, этот какой-то софт для генерации отчетности по шаблонам. Или нет. Наверное, это что-то, что позволит раздирать ТЗ на issue в таск-трекере одним кликом мышки. Начальство даст ему ресурс. Конечно, работа закипит. А еще, кстати, релиз будет довольно быстро. Знаете, почему? Возможно, даже после первых выходных стажер напишет что-то, что уже можно будет кликать и смотреть, как программа выполняет то, что обычно делается руками сутки, за 10 секунд. Быстрый код, цель ясна, интерфейс особо не важен, тесты как-нибудь потом. Светлое будущее.
Фурор. В этот момент мамонтенок появляется на свет. Он маленький, быстрый, всех веселит и мило скачет из переговорки в переговорку.
Обычно, на этом этапе строится предположение о том, как развивать проект:
1) «Серега, 50% времени будешь пилить софтину» — «Ок, босс».
2) «Код держать под замком. Это наше Уникальное Технологическое Преимущество. Конкурентам нини» — «Ок».
3) «Пили функционал, на внешний вид пофиг, это же чисто для работы» — «Ок».
Время в компании бежит довольно быстро, год за годом. 2006-й сменяет 2015-й. 2015-й сменяет 2024-й. Серега давно уволился. Мамонт уже с трудом протискивается между потолком и полом, кроме подготовки отчетности, он переманил на себя сотню — другую корпоративных функций.
Смерть и похороны
В тот момент, когда кто-то из стажеров нашел на гитхабе self-hosted аналог, который написан на React + Rails с Flat Design. А может быть, закрался чужой sales и продал директору SaaS. А может быть, кто-то из компании сходил на конференцию и там услышал, как эти проблемы решают при помощи плагина в google drive… Другими словами, он умер, когда люди увидели, что в мире есть прекрасные оттестированные аналоги, которые решают проблему гораздо лучше.
Как принято в бизнесе, «работает — не трогай». Переведу, это значит, что мамонт будет использоваться еще несколько лет с постепенной миграцией на новомодную находку. И да, ресурсов на его обновление будет выделяться крайне мало. Им будут пугать стажеров, а бывшие сотрудники на корпоративах у конкурентов будут веселить и радовать коллег рассказами о своем пользовательском опыте.
А как иначе? Мы обречены
Да, технологии сменяют одна другую. Но есть возможность разработать что-то внутри компании с прицелом на будущее, а не на настоящее. И есть весьма успешные примеры.
Open source. Сразу. С первого дня
Давайте признаемся себе честно, никого Уникального Технологического Преимущества в 99% внутренних разработок просто нет. В большинстве случаев типовые решения не подходят для компаний, которые построили хитрый и редкий бизнес-процесс и они начинают пилить свое, чтобы IT плотнее прилегало к конвееру. Хватит панически бояться, что конкуренты украдут Вашу систему. Это возможно, но попытайтесь оценить этот риск трезво. Скорее всего софт начнут использовать конкуренты из других городов и стран, рынков и ниш. А самое главное — они начнут его улучшать. От open source можно получить реальные и осязаемые бонусы:
Бесплатных тестировщиков
Высокое качество кода
Большое количество модных Open Source проектов придерживается высокой культуры программирования. Там присутствуют тесты, CI, code-review. Разработать высококачественный продукт в условиях такой обоснованной качественной конкуренции и открытости проще, чем наедине с самим собой, запершись в корпоративном репозитории.
Имидж
basecamp.com/open-source — вот ссылка на страницу одной маленькой компании, внутри которой был разработан Ruby On Rails. Если RoR программист при прочих равных будет выбирать между ней и чем-то еще, выбор будет очевиден. Это просто пример. Тема гораздо более широкая.
Мотивация сотрудников
Программист, который пишет open source, обычно понимает, что одновременно пишет свое резюме. Это может служить нематериальным мотиватором сотрудников, которые работают над внутренней разработкой. Они могут продолжить работать над проектом на другом месте работы, допиливая фичи уже для конкурентов. Но самое главное — ваш мамонт может стать фениксом и жить гораздо дольше.
Lean Startup
Начните внутреннюю разработку так, как если бы вы хотели её продать. И да, продавайте сразу. Это задаст высокую планку качества, позволит обнаружить дыры в бизнес-процессе и разведать конкурентов, получить тонну ценнейшей критики, это даст хорошую оценку продукту в твердой валюте. В любой момент, когда коллега говорит «Какая же классная у нас хреновина вышла!», можно будет спросить, «А сколько копий мы продали?». И ответы на вопрос «Почему так мало?» могут раскрыть самые причудливые ошибки в понимании и построении теперь уже продукта, а не «внутреннего» ПО.
Эпилог
Когда компания разрабатывает что-то для себя, она зачастую хранит это в застенках как зеницу ока. ПО устаревает. Оно устаревает мгновенно и нужно постоянно выделять ресурсы на его развитие, рефакторинг, редизайн, новые интеграции. Очень сложно заставить себя это делать, когда пользователей — 3 человека. Столкните свою разработку с внешним миром. Чем раньше вы это сделаете — тем лучше. Возможно, лучшим фидбеком на ваш прекрасный софт будет: «А почему не взяли эту штуку, зачем пилить свое? github.com/project_author/project_name». Значит, что кто-то уже сделал вашу работу. Не злитесь, что потратили пол года впустую, а радуйтесь, что не потратили еще больше.
Разрабатывайте фениксов, которые будут гармонично перерождаться и приносить пользу год за годом без компромиссов, а не мамонтов, которые завалят бизнес своими костями. Или даже не связывайтесь.
Комментарии (10)
Valistar
17.09.2015 11:45> В мире есть прекрасные оттестированные аналоги, которые решают проблему гораздо лучше.
Зачастую это не так. И про оттестированные это очень громко.
> Open Source 1.Бесплатных тестировщиков
Нету их. Даже если вы будете пиарить Ваш проект.
> Open Source 2.Высокое качество кода
Это иллюзия. Как правильно написал ServPonomarev — оно высокое только если основному разработчику нужна та или иная функциональность. А как только ты используешь проект «по своему» — вылезают новые баги. И основному разработчику решать их нет никакого резона (сроки, бюджеты).
> Open Source 3. Имидж 4.Мотивация сотрудников
Это я считаю важно как для современных компаний так и разработчиков. Но на это надо выделять бюджеты на что готовы не все.
Matvey-Kuk
17.09.2015 14:47Да, согласен, причины смерти мамонта могут быть необоснованными. Но представьте, что ваша внутренняя разработка набирает обороты и сама замещает мамонтов у конкурентов. Шанс необоснованного убийства будет поменьше.
Про отсутствие тестировщиков: я вижу прямо противоположное. Откройте любой более — менее популярный репозиторий на гитхабе — вы найдете целую кучу issue, которые добавили проходящие мимо люди.
Качество кода высокое так же и за счет «правильного» процесса разработки с применением TDD, CI, code-review через PR, которые приняты вы open source. Посмотрите на репозиторий языка Rust для примера. Чтобы туда законтрибьютить, нужно сделать несколько подходов и учесть замечания команды. И люди делают свой вклад даже не смотря на драконовские проверки, потому что понимают обоснованность этого решения.
Конечно, если развивать проект как open source и забить на все принципы работы в этой сфере, упереться в хардкорный enterprise опыт и продолжать применять те же практики (пресс-релизы вместо общения, конференции с sales питчами, технические специалисты по устарелым технологиям), вы получите репозиторий с 1 звездочкой от собственного субподрядчика и треш-кодом в PR от стажеров. Можно будет смело рапортовать начальству, что идея провальная, деньги потрачены, а профита нет.
Но open source — это не просто выложить код на гитхаб, это еще и иной формат работы: публичное планирование, обсуждение фич, сбор обратной связи, формирование сообщества через соцсети и конференции. Это именно не дополнительная работа, а иная. В некоторых случаях большая, в некоторых — меньшая.
Есть примеры компаний, которые выбрали этот путь и результаты воодушевляют.
По поводу бюджетов раскройте пожалуйста мысль.areht
19.09.2015 15:22> с применением TDD, CI, code-review через PR, которые приняты вы open source.
Шутите? Откройте любой любительский проект, в который левые люди не контрибьютят (или 1-2 человека комитят 95%).Matvey-Kuk
19.09.2015 23:59Нет, не шучу. Именно это я и имею в виду. Ваш проект врядли будет популярен, если он написан без соблюдения этих практик. И как только Вы станете искать причины непопулярности у сообщества, тут же наткнетесь на «правильные» пути развития. Open source за Вас работу не сделает, он может помочь сделать её правильнее, если есть желание, но нет умения.
ServPonomarev
Контора, которая пилит решение под свои бизнес-процессы, может выложить свой код в опенсорс. Только этот код никому не будет интересен, по той простой причине, что у конкурентов — свои бизнес-процессы, отличные от. А пилить универсальное решение безсмысленно — бизнесу нужно решение под конкретные имеющиеся бизнес-процессы.
Итог. Никто не будет использовать, тестировать и контрибутить в этот проект. Смысл опен-сорса — теряется.
Matvey-Kuk
Можно выкладывать в open source модули и плагины, которые могут быть использованы другими. Например, мы сейчас планируем пилить внутреннюю систему для контроля разработки и собираемся разделить её на 2 части — opensource ядро (Agile Board для разработчиков со счетчиком времени, который работает на Issue движке Gitlab) и генераторы отчетости, которые будем продавать, либо смиримся и родим мамонта. Но хотя бы ядро будет жить и обновляться, а это больше половины кодовой базы. В тот момент, когда мамонт умрет, нужно будет переписать только несколько гнилых кусков.
Компании тоннами рожают внутренние PHP-фреймворки, JS- библиотеки, сервера очередей и даже базы данных. И хоронят их так же тоннами. В таких случаях частенько их «узкозаточенность под бизнес-процессы» выдумывают из-за незнания best practices и нежелания погуглить или наличия ментального трения в восприятии трендов.
И нет, даже, если этот код никому не будет интересен для использования, это будет портфолио и мотиватор Ваших разработчиков. Да и код, который пишется публично, обычно пишется чище и старательнее. Плюсы все равно есть.
areht
> В тот момент, когда мамонт умрет, нужно будет переписать только несколько гнилых кусков.
Наивная мысль. Мамонт умрёт не весь, и не так, как вы ожидаете. На рынке не будет ничего с совместимым Api (ни на уровне бинарной совместимости, ни кодовой, ни идеологической).
Переписывать придётся много, на порядок больше, чем можно подумать. Поэтому мамонты и живут много лет даже после обнаружения подходящий аналогов
Matvey-Kuk
Не очень понял мысль: «На рынке не будет ничего с совместимым АПИ». Шанс, что совместимость будет с open source проектом, мне кажется, все же выше, чем шанс найти совместимость с проектом, который держится в корпоративных подземельях и гниет там. Если конечно не было отдельных «бюджетов под интеграцию».
Я находил совершенно дикие интеграции, которые писали фанаты той, или иной системы. Что стоит интерпритатор PHP как база для десктоп-Windows приложений с GUI.
К тому-же разработка из моего примера в принципе основана на интеграции с API другой open source системы, что как бы немножко намекает, что если мы будем стараться держать open source составляющую в адекватном состоянии, мы получим рабочую интеграцию с последней версией GitLab на момент смерти мамонта.
И да, я знаю, что они «живут долго после обнаружения аналогов». Только в статье я назвал это «смертью», потому что эти процессы гораздо более похожи. За мою практику такие проекты ничего больше, чем стыд технарей, неудобств, смятения новичков и нежелания о них думать руководства, не вызывают. А еще, да, в тяжелых случаях такая «жизнь» вызывает кадровую текучку. И такое я тоже видел.
areht
Если конечно не было отдельных «бюджетов под интеграцию».
Шанс, что интеграция с проектом, у которого были бюджеты на интеграцию выше, чем с другими. Но, если не придумывать искусственных ограничений, то остальное Вам кажется.
Рабочую интеграцию Вы может и получите, но gitlab к тому моменту будет напоминать «cvslab», то есть какую то старинную даром не нужную штуку