Мы сталкиваемся с разработкой ПО для внутреннего использования постоянно. Веб-студии делают собственные PHP фреймворки (ладно, уже почти все одумались), большие корпорации заказывают кастомные CRM и ERP. Повсеместно, на каждом шагу, каждые несколько секунд один программист или менеджер на нашей планете откатывается от компьютера после 5-и минут гугления готовых решений и говорит «пора пилить свое, это все нам не подходит».
Я попробую рассказать о том, что большинство людей в этот момент забывают. Не важно, что они собираются разработать — библиотеку для обрезки картинок, фреймворк, сложнейший плагин для САПРа или очередную уютную 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… Другими словами, он умер, когда люди увидели, что в мире есть прекрасные оттестированные аналоги, которые решают проблему гораздо лучше.
Как принято в бизнесе, «работает — не трогай». Переведу, это значит, что мамонт будет использоваться еще несколько лет с постепенной миграцией на новомодную находку. И да, ресурсов на его обновление будет выделяться крайне мало. Им будут пугать стажеров, а бывшие сотрудники на корпоративах у конкурентов будут веселить и радовать коллег рассказами о своем пользовательском опыте.
Да, технологии сменяют одна другую. Но есть возможность разработать что-то внутри компании с прицелом на будущее, а не на настоящее. И есть весьма успешные примеры.
Давайте признаемся себе честно, никого Уникального Технологического Преимущества в 99% внутренних разработок просто нет. В большинстве случаев типовые решения не подходят для компаний, которые построили хитрый и редкий бизнес-процесс и они начинают пилить свое, чтобы IT плотнее прилегало к конвееру. Хватит панически бояться, что конкуренты украдут Вашу систему. Это возможно, но попытайтесь оценить этот риск трезво. Скорее всего софт начнут использовать конкуренты из других городов и стран, рынков и ниш. А самое главное — они начнут его улучшать. От open source можно получить реальные и осязаемые бонусы:
Начните внутреннюю разработку так, как если бы вы хотели её продать. И да, продавайте сразу. Это задаст высокую планку качества, позволит обнаружить дыры в бизнес-процессе и разведать конкурентов, получить тонну ценнейшей критики, это даст хорошую оценку продукту в твердой валюте. В любой момент, когда коллега говорит «Какая же классная у нас хреновина вышла!», можно будет спросить, «А сколько копий мы продали?». И ответы на вопрос «Почему так мало?» могут раскрыть самые причудливые ошибки в понимании и построении теперь уже продукта, а не «внутреннего» ПО.
Когда компания разрабатывает что-то для себя, она зачастую хранит это в застенках как зеницу ока. ПО устаревает. Оно устаревает мгновенно и нужно постоянно выделять ресурсы на его развитие, рефакторинг, редизайн, новые интеграции. Очень сложно заставить себя это делать, когда пользователей — 3 человека. Столкните свою разработку с внешним миром. Чем раньше вы это сделаете — тем лучше. Возможно, лучшим фидбеком на ваш прекрасный софт будет: «А почему не взяли эту штуку, зачем пилить свое? github.com/project_author/project_name». Значит, что кто-то уже сделал вашу работу. Не злитесь, что потратили пол года впустую, а радуйтесь, что не потратили еще больше.
Разрабатывайте фениксов, которые будут гармонично перерождаться и приносить пользу год за годом без компромиссов, а не мамонтов, которые завалят бизнес своими костями. Или даже не связывайтесь.
Я попробую рассказать о том, что большинство людей в этот момент забывают. Не важно, что они собираются разработать — библиотеку для обрезки картинок, фреймворк, сложнейший плагин для САПРа или очередную уютную 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». Значит, что кто-то уже сделал вашу работу. Не злитесь, что потратили пол года впустую, а радуйтесь, что не потратили еще больше.
Разрабатывайте фениксов, которые будут гармонично перерождаться и приносить пользу год за годом без компромиссов, а не мамонтов, которые завалят бизнес своими костями. Или даже не связывайтесь.
