Моя организация начала постепенно переориентировать себя на бизнес-модель, менее ориентированную на продукт, и более ориентированную на контракты, за последние год или два. В прошлом году меня перевели в новый подрядный бизнес, чтобы помогать тушить пожары и выполнять заказы. Хотя год в целом был прибыльным (и, следовательно, по крайней мере по одному показателю, успешным, примерно в июне у нас было несколько проектов, которые действительно ухудшили наши показатели за год.
Я разговаривал со своим менеджером перед рождественскими праздниками, и он упомянул, что, хотя ему не нравится термин «вскрытие» (я понятия не имею, что не так с этим термином, какие-нибудь бизнесмены или менеджеры знают?) он действительно хотел провести встречу где-то в середине января, на которой вся контрактная группа проанализирует год и попытается выяснить, что пошло правильно, что пошло не так и какие инициативы мы можем предпринять, чтобы попытаться повысить прибыльность.
По разным причинам (я расскажу подробнее, если это потребуется), я считаю, что одна вещь, от которой наша команда, да и организация в целом, выиграет, - это некая форма организованного совместного использования кода. Одни и те же вещи делают снова и снова разные люди, и в конечном итоге они выполняются (и ломаются) по-разному. Я хотел бы по крайней мере создать репозиторий, где люди могут брать код, который выполняет определенную задачу, и включать (или, реально, копировать / вставлять) этот код в свои собственные проекты.
Что я должен предложить в качестве работоспособного репозитория общих исходных кодов для команды, состоящей как минимум из 10-12 штатных разработчиков, плюс от 5-50 (очень) разработчиков, работающих неполный рабочий день, которые временно переданы в аренду группе по контракту для выполнения специализированной работы ?
Для ответа требовалась некоторая культурная информация, чтобы получить разумный ответ, поэтому я предоставлю ее здесь вместе с некоторыми своими мыслями по этой теме:
- Разработчики не будут вынуждены использовать этот репозиторий. Барьер для входа должен быть как можно более низким, чтобы стимулировать участие, иначе он будет проигнорирован. К сожалению, это означает, что все, что требует установки и запуска дополнительного программного обеспечения, скорее всего, выйдет из строя. Развертывание ClickOnce настолько близко, насколько мы можем, и это ужасно сомнительно.
- Мы не склонны рисковать, магазин Microsoft. Я могу продавать решения с открытым исходным кодом, но к ним будут относиться с подозрением. У всех разработчиков есть VSS, корпоративный директор заявил, что VSTS нежизнеспособна в будущем. Если это не слишком сложно, а лицензия свободна, я все равно могу попробовать внедрить VSTS-сервер в лабораторию.
- Некоторые из моих коллег-разработчиков заботятся о написании качественного и надежного программного обеспечения, некоторые - нет. Я хотел бы защитить любой общий код, написанный теми, кому это небезразлично, от тех, кто этого не делает. Общие методы управления конфигурацией (например, проверка кода во время работы над ним) полностью игнорируются по крайней мере пятой частью моих коллег по команде по контракту.
- Мы лучше пишем процессы, чем следуем им. Мне в значительной степени потребуется какой-то письменный процесс, чтобы я мог продать это моему руководителю. Я считаю, что он должен быть легким, гибким и реализованным с помощью инструментов, чтобы он был актуален удаленно, потому что мой менеджер - единственный человек, который когда-либо его прочитает.
- Не применяйте передовой опыт. Я бы очень хотел включить такие вещи, как обязательные обзоры кода, чтобы принудительно использовать инструменты статического анализа (FxCop, StyleCop) для общего кода. Однако это поднимает планку, потому что в настоящее время такие практики не выполняются последовательно.
Буду рад предоставить любую дополнительную запрошенную информацию. :)
РЕДАКТИРОВАТЬ: (Отвечая на вопросы)
Возможно, контракт - неправильный термин. Мы абсолютно владеем собственными активами кода. Значительная часть бизнес-модели на бумаге (хотя и не на практике) заключается в том, что нам принадлежит код / проекты, которые мы пишем, и мы можем перепродавать их другим клиентам. Наши проекты обычно представляют собой добавление некоторых специальных функций к одному из многих существующих программных продуктов компании.
