Black_beard_ast
@Black_beard_ast
Sysadmin/Ops engineer.

Как бы вы приняли проект на поддержку/сопровождение?

Представьте ситуацию - вам(компании) продали действующий проект и вы принимаете его на эксплуатацию. Вы системный-инженер, на котором вся инфраструктура/бд/по. Как бы вы его принимали? Какие моменты учли-бы? Проект оч. большой, стек примерно такой - apache/nginx/php/couchbase/mysql/rabbitmq/cassandradb/memcached/etc с кубернетсом/ансибль-ем/докером и пр зоопарком технологий.
  • Вопрос задан
  • 211 просмотров
Пригласить эксперта
Ответы на вопрос 3
@electronik777
1) Нужно понимать что делает этот проект, и выполняет ли задачи которые на него возложили. Нет ли еще не реализованных фич, незакрытых багов, про которые знает только пара людей. Потому что на бумаге фича есть, а по факту она, еще не на 100% сделана, а только заложили на будущие какие то модули, или баг который воспроизводится в определённой последовательности, но вероятность попасть на неё крайне мала. Так же нужно понимать кол-во пользователей у этого проекта, чем больше тем хуже для Вас т.к доступность проекта должна быть не менее 99.95%

2) Если бы я принимал проект с таким стэком технологий и всё сопровождение ложись бы на меня, я бы потребовал документацию по этому проекту, всё что только есть, чего нет должны будут дописать старые сотрудники. И дополнительно поддержка не менее 6 месяцев(возможно платная-тут нужно рассматривать варианты).

3) Понимание стэка который используется, если вы все эти технологии знаете на среднем уровне, то хорошо, если нет искать людей на аутсорсе которые Вам объяснят что к чему и помогут за деньги поддерживать проект на плаву.

4)Обязательно заказать аудит от незаинтересованных лиц. Если бюджет позволяет, то от двух компаний. Так же проверить модули/код которые используются в проекте на "юридическую чистоту", что бы не было ограничений на продажу проекта, предоставление проектом коммерческих услуг(платные подписки и т.п) т.к есть модули которые бесплатны для собственного использования, но платные для коммерческого использования(тут подпадает и продажа проекта, и предоставление платных опций пользователям проекта и т.п). Ну и что бы в случае чего проблемы легли на разработчика либо компанию которая делала аудит.

5)Понимать свою компетенцию, насколько Вы готовы отвечать за то что Вам передают. Опять же проект разрабатывала целая команда, а сейчас его вешают целиком на Вас. Вы в состоянии поддерживать этот проект? А развивать, фиксисть баги? Если нет, то тогда первым делать искать людей которые это могут, и принимать всем в месте. Делить проект на части и делить эти части между компетентными сотрудниками которые в состоянии в случае чего аргументировать своё решение/мнение.

Ну для начала как то так, то что пришло в голову сразу, на самом деле там еще очень много всего. Всё зависит от конкретной ситуации.
Ответ написан
Комментировать
Sanes
@Sanes
Как минимум вы не можете давать никаких гарантий.
Принимаете проект, изучаете его и поддерживаете. Цена зависит от сложности, документирования и много-много всего другого.

Обычно после смены собственника, какое-то время старая команда работает параллельно и вводит в курс дела.
Ответ написан
@AtaZ
кто знает, тот поймет
Если отбросить профессиональные навыки, т.е. предположить, что все компетентны по всем частям проекта, то советую у передающей стороны выпросить все текущие косяки, недоработки и костыли так вы сразу поймете истинное положение дел.

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

Если проект автономен (не требует поддержи 24/7), то документация ваш лучший друг, в противном случае времени на документацию не будет, это обычная практика в больших проектах.

Ну и наконец пользователи. От их адекватности зависит как быстро вы адаптируетесь в проект, иногда пользователи могут рассказать больше чем разработчик)
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы