По поводу стандартизации процесса разработки — тут важно определить, что подразумевается под «стандартизацией». Является ли стандартизацией процесса разработки принятый в компании Code style? Кажется, что да, но бывает, что не все разработчики соблюдают Code style, и иногда это может считаться вполне оправданным (например, при внесении изменений в legacy проект, где весь код написан по другим стандартам).
В нашей компании использование «базового модуля» не является стандартом. К каждому проекту мы подходим индивидуально. Многое зависит от типа проекта и от опыта команды разработки, которая будет его делать. Использовать или нет базовый модуль, команда принимает самостоятельно. Но если «базовый модуль» используется на проекте, то «стандартизация» проявляется в том, что появляется некая «структура» (рамки) и правила, которые нужно учитывать при написании нового кода.
По поводу сокращения времени на запуск новых проектов — это сложно оценить, если не собирать метрики. По нашему опыту: для нескольких проектов, где мы с заказчиками изначально согласовали существенно меньший бюджет проекта на основании того, что при реализации этого проекта будут использоваться наши «внутренние модули», мы в итоге в эти «сокращенные» бюджеты уложились. В целом: «стандартизировать» лучше то, что уже проверено и улучшено посредством нескольких итераций. Чтобы понять, «ускорилось» что-то или нет, нужно отслеживать «как у нас сейчас» и «как стало после применения».
Вопрос о том, что выгоднее, стоит рассмотреть с двух точек зрения: кому это выгоднее?
Для заказчика, который хочет создать интернет-магазин по типовому шаблону в сжатые сроки и с ограниченным бюджетом, выбор «готового решения» (например, от «Аспро») может стать хорошей альтернативой разработке с нуля. Выгодно ли это таким заказчикам? Вероятно, да.
Мы проанализировали запросы наших клиентов и пришли к выводу, что процент таких запросов остается стабильным, если не увеличивается. Учитывая, что некоторые заказчики обращаются к нам за технической поддержкой проектов, созданных на основе «готовых решений», мы были вынуждены повысить квалификацию своих разработчиков в работе с этими решениями. Теперь у нас есть специалисты по «Аспро» и другим популярным готовым платформам.
Если говорить про нас как компанию, то нам, конечно, выгоднее продавать собственные решения вместо использования сторонних. Это выгодно и нашим заказчикам, если мы осуществляем дальнейшее сопровождение проекта. Если эта функция будет передана другим подрядчикам или выполняться силами заказчика, выгода может быть не столь очевидной. Мы прилагаем все усилия, чтобы сделать процесс максимально простым и удобным: предоставляем документацию, консультируем и поддерживаем.
Спасибо за комментарий. Рад, что информация оказалась полезной для вас.
Процесс адаптации новых разработчиков к проекту является крайне важным аспектом. Ведь использование внутренних модулей требует от новичков дополнительных усилий для изучения их работы и навыков применения. И тем самым повышает «порог входа» при онбординге нового разработчика на такой проект.
Поэтому необходимо заранее продумать меры, которые могли бы облегчить адаптацию. Например, можно организовать внутреннюю презентацию для разработчиков, которая будет доступна в записи. Также важно предоставить открытую и исчерпывающую документацию, а также обеспечить наличие внутренних экспертов в команде, которые смогут помочь с любыми вопросами, связанными с реализацией.
По поводу вовлечения разработчиков — это не менее важный аспект, поскольку часто можно столкнуться с их сопротивлением, когда новые инициативы пытаются навязать сверху.
Чтобы избежать подобных трудностей, необходимо обсудить новый подход к разработке внутри команд. Все участники должны понимать, какую пользу он может принести и какие проблемы способен решить. Важно, чтобы нашлись лидеры, готовые продвигать этот подход, а также возможность отказаться от него, если он не оправдает ожиданий.
Можно подойти к изменениям постепенно: реализовать один-два «пилотных» проекта, собрать обратную связь от разработчиков и заказчиков, а затем принять решение — отказаться от этого подхода или улучшить его и использовать в дальнейшем.
Да, страницы создаются на php. Но в Битриксе есть возможность добавлять разные шаблонизаторы. Но для того, чтобы их добавить, нужно еще потрудиться и покодить. Ну по сути для Битрикса это не сильно актуально.
Спасибо за оценку.
По поводу стандартизации процесса разработки — тут важно определить, что подразумевается под «стандартизацией». Является ли стандартизацией процесса разработки принятый в компании Code style? Кажется, что да, но бывает, что не все разработчики соблюдают Code style, и иногда это может считаться вполне оправданным (например, при внесении изменений в legacy проект, где весь код написан по другим стандартам).
В нашей компании использование «базового модуля» не является стандартом. К каждому проекту мы подходим индивидуально. Многое зависит от типа проекта и от опыта команды разработки, которая будет его делать. Использовать или нет базовый модуль, команда принимает самостоятельно. Но если «базовый модуль» используется на проекте, то «стандартизация» проявляется в том, что появляется некая «структура» (рамки) и правила, которые нужно учитывать при написании нового кода.
По поводу сокращения времени на запуск новых проектов — это сложно оценить, если не собирать метрики. По нашему опыту: для нескольких проектов, где мы с заказчиками изначально согласовали существенно меньший бюджет проекта на основании того, что при реализации этого проекта будут использоваться наши «внутренние модули», мы в итоге в эти «сокращенные» бюджеты уложились. В целом: «стандартизировать» лучше то, что уже проверено и улучшено посредством нескольких итераций. Чтобы понять, «ускорилось» что-то или нет, нужно отслеживать «как у нас сейчас» и «как стало после применения».
Вопрос о том, что выгоднее, стоит рассмотреть с двух точек зрения: кому это выгоднее?
Для заказчика, который хочет создать интернет-магазин по типовому шаблону в сжатые сроки и с ограниченным бюджетом, выбор «готового решения» (например, от «Аспро») может стать хорошей альтернативой разработке с нуля. Выгодно ли это таким заказчикам? Вероятно, да.
Мы проанализировали запросы наших клиентов и пришли к выводу, что процент таких запросов остается стабильным, если не увеличивается. Учитывая, что некоторые заказчики обращаются к нам за технической поддержкой проектов, созданных на основе «готовых решений», мы были вынуждены повысить квалификацию своих разработчиков в работе с этими решениями. Теперь у нас есть специалисты по «Аспро» и другим популярным готовым платформам.
Если говорить про нас как компанию, то нам, конечно, выгоднее продавать собственные решения вместо использования сторонних. Это выгодно и нашим заказчикам, если мы осуществляем дальнейшее сопровождение проекта. Если эта функция будет передана другим подрядчикам или выполняться силами заказчика, выгода может быть не столь очевидной. Мы прилагаем все усилия, чтобы сделать процесс максимально простым и удобным: предоставляем документацию, консультируем и поддерживаем.
Спасибо за комментарий. Рад, что информация оказалась полезной для вас.
Процесс адаптации новых разработчиков к проекту является крайне важным аспектом. Ведь использование внутренних модулей требует от новичков дополнительных усилий для изучения их работы и навыков применения. И тем самым повышает «порог входа» при онбординге нового разработчика на такой проект.
Поэтому необходимо заранее продумать меры, которые могли бы облегчить адаптацию. Например, можно организовать внутреннюю презентацию для разработчиков, которая будет доступна в записи. Также важно предоставить открытую и исчерпывающую документацию, а также обеспечить наличие внутренних экспертов в команде, которые смогут помочь с любыми вопросами, связанными с реализацией.
По поводу вовлечения разработчиков — это не менее важный аспект, поскольку часто можно столкнуться с их сопротивлением, когда новые инициативы пытаются навязать сверху.
Чтобы избежать подобных трудностей, необходимо обсудить новый подход к разработке внутри команд. Все участники должны понимать, какую пользу он может принести и какие проблемы способен решить. Важно, чтобы нашлись лидеры, готовые продвигать этот подход, а также возможность отказаться от него, если он не оправдает ожиданий.
Можно подойти к изменениям постепенно: реализовать один-два «пилотных» проекта, собрать обратную связь от разработчиков и заказчиков, а затем принять решение — отказаться от этого подхода или улучшить его и использовать в дальнейшем.
Да, страницы создаются на php. Но в Битриксе есть возможность добавлять разные шаблонизаторы. Но для того, чтобы их добавить, нужно еще потрудиться и покодить. Ну по сути для Битрикса это не сильно актуально.
Тут еще можно почитать: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=3235&ysclid=m1ktie6elk969199473
спасибо) рад, что понравилось. опыта накопилось достаточно, пора делиться