Как снизить зависимость от разработчиков?

Question

[Johnny_Cash]

Мы заказчики веб-сайтов и не разбираемся в программировании вообще. Мы понимаем "ЧТО" мы хотим получить, но в технической части реализации задачи знания нашей команды очень поверхностны. Это увеличивает количество рисков и хрупкость будущих проектов.

Например сейчас выбираем между заказом нового сайта на одной из CMS или на популярных Framework.

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

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

Вопрос, что лучше CMS или Framework будет неправильным, поэтому спрошу по-другому:

В каком из вариантов: CMS или Framework зависимость от разработчиков будет меньше? Если они улетят на Марс, уйдут из бизнеса, из жизни итд.

Вопрос 2. Есть ли удобный способ для заказчика проверить качество кода, который пишет разработчик?

Comments

[Ярослав Иванов]

Мы заказчики веб-сайтов и не разбираемся в программировании вообще.

код, который пишет компания-разработчик вряд ли будет лучше, нежели у готовых CMS.

[Александр Синицын]

Все зависит от разработчика. Если он пишет по методологии, то другие его поймут достаточно быстро. Это касается и CMS, и Framework-ов... и то и другое легко превратить в велосипед без документации, состоящий из нагромождения запутанного кода.

[lamer350]

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

Большое заблуждение. Если вы продаете носки, магазин чисто технически простой - да, возможно кое с чем сможете смерится и использовать, но в 90% случаях нужны сразу доработки и/или с обновлениями что то ломается. К тому же сами разработчики дешевле - а значит и качество разработки хуже (как правило).

Основной аргумент в пользу Framework: он позволяет делать любые доработки, не замедляя и усложняя работу сайта костылями.

Такое же заблуждение как и с cms. Замедляет и усложняет сайт неправильная архитектура проекта, количество запросов в базу, наличие или отсутствие кеширования и тп. фреймворк - это еще ничего не значит, главное скилы команды!

[Антон]

По существу вопроса: Если вы нихрена не понимаете в разработках, коде, что и как устроено, то какая вам разница CMS или Framework, тем более вы плохо понимаете разницу между двумя этими словами. Зависимость есть всегда, особенно если ваш бизнес склонен к масштабированию и отличен сколько-нибудь от традиционной интернет-торговли.

наш магазин

Вы много знаете серьезных систем для развертывания магазина (с интеграцией банка, курьерской и почтовой службой, с маркетплейсами и системами 1С и Crm)?
Вы в курсе, что большинство велосипедов и костылей делается не потому, что разработчики плохие, а потому что заказчики требуют исполнения своих "хотелок" в разрез логики и здравого смысла?
И самое главное - использование платформы всегда ниже в стоимости, чем услуги компании-разработчика.

сейчас выбираем между заказом нового сайта на одной из CMS или на популярных Framework

Сначала пишут хотелки, делают ТЗ, планирование и архитектуру, учитывая бизнес процессы и логику, а потом выбирают реализацию...

[Johnny_Cash]

lamer350,

Большое заблуждение. Если вы продаете носки, магазин чисто технически простой - да, возможно кое с чем сможете смерится и использовать, но в 90% случаях нужны сразу доработки и/или с обновлениями что то ломается.

Спасибо. Приму к сведению.

К тому же сами разработчики дешевле - а значит и качество разработки хуже (как правило).

Не понятно что Вы имели ввиду. Перефразируйте или объясните

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

Возможно это и полезная информация для программистов. Но для нас это "философское" изречение - оно не имеет практической ценности. Нет возможности сформировать и проверить правильность архитектуры, протестировать и сделать рейтинг скилов команд агенств-претендентов

Answer 1

[Владимир Коротенко]

Странно все это стало. На 3 х последних собеседованиях меня спрашивали а вы не уйдёте в закат? Общее правило для вас. Не обижайте разработчиков. В договоре пропишите передачу имущественных прав на код. Документируйте все решение, синхронизируйте код и проектную документацию. Я бы все же выбрал Фреймворк, тут и все те плюсы что вы описали и оптимизация для ceo и легкая интеграция с бэк офисом и платёжными системами и отсутствие костылей потому что программа делает только то что нужно. По уму конечно лучше взять в штат программиста который будет поддерживать ваш проект.

Comments

[Johnny_Cash]

Спасибо за рекомендации. Объясните пожалуйста как синхронизировать код и проектную документацию? Как правильно документировать решения?

Ни в коем случае не хотели кого-то обидеть. У каждого свой опыт. Предыдущая компания, которой мы заказывали сайт, переформатировала свою работу и "умыла руки" от поддержки проекта. Несколько других компаний не смогли выполнить обновление платформы Opencart 1.3 на вторую, или третью версию: что-то слетало, переставало работать и т.д.

[Владимир Коротенко]

Johnny_Cash,
1. ТЗ основа основ.
2. Система контроля версий.
3. Багтрекер
4. Акт приема (и оплата)

То есть цепочка изменений идет через 4 этих пункта.
По идее любая контора получившая на руки ТЗ, в состоянии развернуть решение и стартовать процесс доработки. Либо что то не правильно.

[Johnny_Cash]

Владимир Коротенко, Первый и четвертый пункты - понятно. 2 и 3 - это для меня китайская грамота. Это внутренние механизмы разработчиков.

По идее любая контора получившая на руки ТЗ, в состоянии развернуть решение и стартовать процесс доработки.

Во-первых всего в ТЗ не предусмотришь. Понимаю, что это наша проблема, а не агенства. После запуска проекта однозначно нужны будут доработки: что-то неправильно рассчитали; что-то уже успело измениться в бизнесе; еще родилась идея; причин может быть миллион. ТЗ сегодня и через год будут разными. Вопрос, как сделать так, чтобы обновление и доработка проекта были комфортными, чтобы каждое новое обновление не усложняло следующее, чтобы все вносимые доработки не замедляли работу сайта?

Только не отвечайте со стороны программиста: нужно грамотно код написать, четко все задокументировать и т.д. Лучше дайте совет, как работать с агенством, как выбирать и т.д. Спасибо;)

[Владимир Коротенко]

Johnny_Cash,

2 https://training.github.com/downloads/ru/github-gi...
3 https://www.redmine.org/

В ТЗ нет. Но вы должны выстроить рабочий процесс. Который состоит из опроса конечных пользователей, внесения изменений в ТЗ, кодирования и фиксации в системе контроля версий, фиксации работы в багтрекере (сколько времени ушло, что за номер бага, фичи, раздел в ТЗ) и как результат отчета из багтрекинга акт приемки.

Answer 2

[Сергей delphinpro]

ограничения редактирования CMS, т.е. если мы захотим что-то дописать - это будут костыли,

Вовсе нет.
CMS - это не всегда закрытый ящик. Если взять к примеру joomla, wordpress, modx (из тех что я знаю) — то они достаточно гибко дописываются. Тут вопрос в том, насколько хорошо разраб знает эту систему. Если хорошо, то он напишет расширенный функционал не "на костылях". С другой стороны, даже если говорить о фреймворке и о разработчике, который плохо его знает, то он и там будет писать костыли, только потому, что не в курсе имеющихся средств и инструментов из комплекта поставки или популярных пакетов.
Резюмируя — количество костылей обратно пропорционально квалификации программиста, вне зависимости от используемого инструмента.

CMS или Framework зависимость от разработчиков будет меньше?

Зависимость тем меньше, чем популярнее выбранное решение. Найти разработчика на условный вордпресс проще, чем на неизвестную AweCMS.

Есть ли удобный способ для заказчика проверить качество кода, который пишет разработчик?

Тут я не претендую на истину, но мне кажется единственный способ проверки, не имея собственной квалификации — нанять аудитора. Но тут возникнет вопрос компетентности аудитора =)

Comments

[Ярослав Иванов]

Нанять аудитора чтобы проверил аудитора))

[Сергей delphinpro]

Ярослав Иванов, это опасно =)
можно уйти в infinite recursion и словить stack overflow

[Владимир Коротенко]

Ярослав Иванов, кто будет охранять пастухов:; эта дилемма решена ещё в древней Греции

[Johnny_Cash]

Резюмируя — количество костылей обратно пропорционально квалификации программиста, вне зависимости от используемого инструмента.

Это однозначно! Но так как у нас нет нужных знаний, чтобы выбрать квалифицированного программиста, правильного аудитора и других, нам нужно задавать "правильные вопросы" и знать как проверить уровень.

Хорошее решение в подобных случаях - работать с лидером рынка. Но ценник там х3 в сравнении с просто хорошим агенством.

[Johnny_Cash]

Владимир Коротенко, расскажите о решении греков?

[Сергей delphinpro]

Johnny_Cash,

нам нужно задавать "правильные вопросы" и знать как проверить уровень.

То есть — повысить свою квалификацию =)

Еще один из способов снижения зависимости от разработчика — жесткое требование документировать весь новый код/функционал, чтобы новому разработчику было проще стартовать.

[Johnny_Cash]

Сергей delphinpro,

То есть — повысить свою квалификацию =)

Однозначно! из ответов я уже почерпнул много полезной информации. Есть практические рекомендации как повышать квалификацию в этом руководителю бизнеса неайтишнику?

Answer 3

[Антон Швец]

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

Из этих пунктов следует один вывод. Хорошо это всегда дорого, по другому не бывает.

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

Comments

[Владимир Коротенко]

Вы не менеджер, бизнес бывает хочет попробовать идею, и на 90% уверен что ее выбросят смысл напрягаться?

[Johnny_Cash]

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

Мы планируем разрабатывать сайт. Я знаю о системе проверки перед тем, как принять работы. Но как "Хорошо покрыть тестами готовый продукт"?

В каком виде будет "инструмент для проверки работоспособности" и как им пользоваться?

Answer 4

[Sanes]

В каком из вариантов: CMS или Framework зависимость от разработчиков будет меньше? Если они улетят на Марс, уйдут из бизнеса, из жизни итд.

Экзотический софт не выбирайте и всё будет нормально.

Вопрос 2. Есть ли удобный способ для заказчика проверить качество кода, который пишет разработчик?

Стать разработчиком или отдать кому-то на проверку

Answer 5

[Adamos]

1. Вы не будете зависеть от разработчиков, если будете применять широко распространенные решения.
2. Как только разработчики дописывают что-то конкретно под вас - привет, зависимость.
3. И да, не надо думать, что широко разрекламированные решения действительно подходят под первый пункт ;)

Comments

[Владимир Коротенко]

Смотрите по 1 пункту. Я пишу на шарепоинт но чтобы въехать в проект нужно примерно от недели до месяца

[Adamos]

Владимир Коротенко, я сказал "решения", а не "технологии".

[Владимир Коротенко]

Adamos, Это и есть решение. SharePoint это довольно известное решение. С огромным коммунити и решениями на практически каждую задачу, правда от этого не легче

[Adamos]

Владимир Коротенко, если вы на нем "пишете" - это не готовое решение.
1С - решение, выгрузки - зависимость.
Офис - решение, макросы - зависимость.
WooCommerce - решение, нестандартный магазин на его базе - зависимость...

[Владимир Коротенко]

Adamos, Я немного посмеюсь. Все что вы привели в примере это решения, как и шарик. Но бизнес он не 3 копейки, и каждый бизнес хочет кастомизации.

Где то логотипа, а где то "Нам нужно копирование данных между тенантами для обеспечения синхронизации wiki между нашим сайтом и сайтом клиента"

[Adamos]

Владимир Коротенко, ну, и возвращаясь к вопросу - каждая кастомизация не создает зависимости от кастомизатора только в том случае, если она детально документирована, причем желательно не самим кастомизатором.

[Владимир Коротенко]

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

Я не доверяю клиентам, они раздолбаи

[Adamos]

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

[Владимир Коротенко]

Adamos, С чего вы взяли?
Это моя личная система быстрого воспоминания проекта. А так код абсолютно прозрачен. Только вы на то что бы понять потратите день или 2 - 3 недели, в зависимости от размера.

[Adamos]

Владимир Коротенко, я не дотнетчик, так что вы мне льстите ;)

[Владимир Коротенко]

Adamos, это не относится к языку. Любой нормальный разработчик вырабатывает систему для быстрого воспоминания своих проектов. Своеобразный мнемокод. Формализовать это сложно, особенно для команд с разными стилями разработки

Answer 6

[tundramani]

секрет простой - разработкой должны заниматься только разработчики
а не эффективные манагеры которые не умеют разрабатывать

должен быть главный разраб который отвечает за качество
он контролирует работу разрабов и нанимает их на работу

если так не делать то будет то что как обычно есть в наших краях - отвратительный продукт

аналогично и в работе нашего государства - разработкой занимаются некомпетентные люди

Answer 7

[Qualiant]

код, который пишет компания-разработчик вряд ли будет лучше, нежели у готовых CMS.

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

если разработчик исчезнет - другие специалисты могут просто не разобраться в том, что он написал и эффективно вносить туда изменения.

"Умение разбираться в чужом коде".

Смешно. Если человек умеет писать - он сможет и прочитать. Не может прочитать - не умеет писать.

А вообще, требуйте настолько подробную документацию по платформе, чтобы вы сами почитав её смогли всё понять.

И что такое "эффективно"? Это сколько секунд между постановкой задачи и введением её решения в эксплуатацию?

В каком из вариантов: CMS или Framework зависимость от разработчиков будет меньше?

Ни в каком.

Есть ли удобный способ для заказчика проверить качество кода, который пишет разработчик?

Есть ли у клиента удобный способ проверить насколько качественно отремонтировали двигатель его автомобиля? Косяк ремонта может проявиться и через несколько метров, и через несколько месяцев. То же самое и с разработкой.

Answer 8

[Алекс Глебов]

CMS или на популярных Framework

Если достаточно накликать мышкой нужный функционал, то cms.

большинство функционала, который нам нужен, уже кем-то использовался.

Для фреймворков тоже есть готовый функционал, в open souce репозиториях, почти для всех часто встречающихся задач.

код, который пишет компания-разработчик вряд ли будет лучше, нежели у готовых CMS

В большинстве cms такой гкод, что более менее серьезные разработчики не будут в этом копаться.

Есть ли удобный способ для заказчика проверить качество кода

Нужен эксперт, которому доверяете и который будет вести проект, подбирать разработчиков и делать ревью.
Без этого будет черти что. На фрилансе 99% тех, кого в офис не взяли, а отобрать из них способных без знаний не получится. Со студиями дела лучше. В целом, стоит смотреть по портфолио, но свой эксперт и тут не помешает.

если разработчик исчезнет - другие специалисты могут просто не разобраться

Если код действительно качественный, и технологии не редкие, то проблем с поиском новых людей не будет.

В каком из вариантов: CMS или Framework зависимость от разработчиков будет меньше?

Без разницы, просто другой уровень разработчиков.

Comments

[Johnny_Cash]

Спасибо за рекомендации.

Answer 9

[Vadim Rublev]

(Комменты не читал.)
Скажу как заказчик (бывший), и как фулл-стэк веб-программист (настоящий):
Никак эта проблема нормально не решается. Уж точно не решить её тем выбором, который вы себе определили (CMS / Framework).
Идеально: делать с нуля; на ванильных ЯП; программистами в штате; с нормальной Документацией (и системой тестов, разумеется). Это самый затратный вариант, но по итогу самый лучший (и дешёвый по деньгам в итоге).
Самый фейл-вариант - работать с приходящими фрилансерами. Если уж фрилансер(ы), то один постоянный (аналог штатного программиста, но штатный лучше, конечно).

Comments

[Johnny_Cash]

У нас не настолько уникальный проект, чтобы делать с нуля.

По фейл-варианту - согласен)

[Vadim Rublev]

Та я ж не агитирую. За "с нуля".
Вам виднее как делать.

Сами со временем поймёте. )

[Vadim Rublev]

Тут есть ещё один нехилый подводный булыжник - каждый новый прогер может (сделав успешно свою задачу) испортить уже имеющийся код. Нереально после каждой завершённой задачей тестировать весь проект с нуля. Тут остаётся тупо доверять, что человек не отредактировал что-то, что было дО него (хотя вполне возможно, что его задача включает и редактирование имеющегося). )....
Мораль: чтобы не зависеть от программиста, надо исключить его участие. )
Можете попробовать сами сделать всё на "Делфи" или "Дримвэйвере".

[Johnny_Cash]

Мораль: чтобы не зависеть от программиста, надо исключить его участие. )

Записал себе в цитатник)))

[Vadim Rublev]

Ну вот в указанных системах можно же без программиста обойтись. )

Answer 10

[uvelichitel]

Мы заказчики веб-сайтов и не разбираемся в программировании вообще ... в технической части реализации задачи знания нашей команды очень поверхностны.

Звучит как то неправдоподобно. Кто "мы" и в чем же, интересно, глубоки знания таинственной "команды заказчиков веб-сайтов"?