Pull to refresh

Как должна работать компания по web-программированию

Reading time 7 min
Views 16K
imageИстория этой статьи началась лет как минимум семь назад когда поработав в одной немецкой web-компании я перешла под крылышко крупного конечного заказчика и начала работать удаленно.

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

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

И вот тогда в конечном итоге решилась эти само собой разумеющиеся, очевидные для меня вещи оформить в такой себе «манифест» (хе-хе), концепцию, описание и список того, без чего, имхо, работать компании не стоит. Уточню, что речь пойдет не о работе с клиентом, не о менеджменте как таковом, не о деньгах и бизнес-планах, а об организации работы небольшой фирмы разработчиков под веб (и, возможно, не только под веб), о том, что надо делать, чем важно заниматься чтобы работать успешно и развиваться.

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

Начнем с определений.
Небольшая группа (5-6 человек) разработчиков объединяются в компанию (фирму) для того, чтобы работая:
  • получать от деятельности этой компании доход,
  • получать удовольствие от этой работы и результатов.


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

Иными словами предоставлять клиенту полный цикл работ начиная от планирования и заканчивая продвижением веб-сайта. Порядок в этом списке, конечно, очень важен. Здесь мы делаем акцент на разработке/программировании, декларируем, что будем заниматься системным администрированием, но только в пределах хостинга как правило собственных проектов и не собираемся здесь конкурировать с кем бы то ни было. Нам нужен также дизайн для наших проектов, но мы не позиционируем себя как веб-студия, дизайн для нас не является приоритетным направлением развития. А поддержка и SEO и вовсе второстепенны и важны только в контексте полного цикла услуг.

Из человеческого ресурса для начала нам достаточно нескольких разработчиков/программистов, способных к самообучению, к росту в команду с целью ее последующего расширеня и трансформации в будущем в несколько подобных команд (подразделений). Обязательно должен присутствовать грамотный системный администратор. Нужны также дизайнер и «сеошник», возможно поначалу и не на постоянной основе. И, возможно, самое главное — нужен заинтересованный лидер. Директор, менеджер проектов, аналитик, организатор и еще много чего в одном лице.

Важно также определиться с базовыми ценностями. С целью стабильного развития компании в будущем мы хотим обеспечить возможность профессионального роста для каждого сотрудника и максимально стимулировать и упростить процесс обмена знаниями и информацией между разработчиками. Атмосфера открытости и стремления учиться и — особенно — делиться знаниями должны всячески поощряться (кроме всего прочего такая атмосфера сама по себе служит отличным мотивационным фактором). Однако направление всего процесса в разумное русло тоже является обязательным и здесь не обойтись без некоторых ограничений. И самое важное, чего мы хотим добиться в результате таких ограничений, это взаимозаменяемость разработчиков насколько это возможно, конечно.

В качестве отступления несколько слов о материальном (о рабочих станциях). В идеале, если конечно мы не занимаемся разработкой под продукты компании Microsoft, здесь не использовать проприетарное ПО. Опыт показывает, что сегодня open source решений для нас вполне достаточно и вполне логичным видится держать только одну машину в офисе под MS Windows (для дизайнера, визуального тестирования). Не имеет смысла однако ограничивать разработчиков рамками, например, только одного дистрибутива Linux, здесь каждый вправе организовывать собственное рабочее место так, как ему больше нравиться (за исключением общих инструментов — см. ниже). Имеет смысл однако всю (или почти всю) разработку вести на внутреннем development-сервере (см. также ниже) и для этих целей не поскупиться на хорошее железо и сеть.

Ок, допустим, что понимание всего этого у нас есть и роли ми распределили.
Как же должна работать команда?

На мой взгляд, следующие вещи/практики/подходы в наше работе обязательны.
Итак, Важно:
  1. Использовать единый стиль кодирования (нотация и общие принципы). Оформить правила небольшим документом.
  2. Общее IDE и общий набор других инструментов (напр. программ для работы с базами данных). Мессенджер, конечно, каждый может использовать какой кому нравится, но работая по одной технологии нельзя держать зоопарк IDE даже если это и не стоит денег.
  3. Использование системы контроля версий для ВСЕХ проектов. Имеет смысл хотя бы для просмотра кода (как минимум для поиска «где же я это уже делал?»), для развертывания, для откатов и переделок по желанию клиента даже если над проектом работает только один человек. Имхо, предпочтительна для нашей компании все таки не распределенная, а централизованная организация репозитария.
  4. Ведение всех проектов через единую систему управления проектами (PMS): базовое планирование, task tracking, request and bug tracking, учет времени, частично CRM. Желательно, конечно, написать свою под собственные нужды, но можно поставить и готовую, не желательно, однако, с моей точки зрения, использовать сторонний сервис. Нельзя допускать ситуации, когда, например, файлы от заказчика или переписка лежат там, куда их решил сохранить менеджер проекта (как правило, в папке у себя на рабочем столе) — для размещения всех документов есть строго определенный порядок.
  5. Обязательное использование (создание, пополнение, актуализация) ресурса с документацией, книгами, файлами справки etc. — общая база знаний. Вынесение фрагментов кода и пошаговых инструкций в общий для компании структурированный wiki-ресурс.
  6. Очень и очень желательно тестировать код. Модульное тестирование (Unit tests) для особо критичных частей проекта, а в идеале — TDD как норма жизни.
  7. Использовать единый стиль документирования кода под одну определенную систему генерации документации. Документация, однако, предоставляется и поддерживается только по проектам, где это оговорено дополнительно.
  8. Команда должна хорошо владеть одним-двумя фреймворками и использовать только их для разработки относительно сложных проектов.
  9. Использовать одну-две CMS для относительно простых и простейших проектов, изучить их желательно всем членам команды.
  10. В то же время стоит работать с относительно бОльшим числом СУБД.
  11. Постоянно работать над самообразованием, обучением новых работников, стажеров. В первую очередь путем проведения общих еженедельных семинаров. Также желательно регулярно проводить разборы фрагментов кода, иногда практиковать парное программирование.
  12. Планировать освоение новых технологий и методологий работы. Осуществлять плановый переход на новые версии программного обеспечения.
  13. Стремиться вести грамотное планирование работ по проектам, отдавать предпочтение итерационному планированию с коротким циклом. Обязательно оценивать реальные затраты, скорость групп разработчиков и т.п., делать анализ и выводы после закрытия каждого проекта, очень желательно отражение этого в PMS.
  14. Помимо планирования и ведения задач обязательно писать короткую техническую спецификацию на каждый проект и поддерживать ее в актуальном состоянии.
  15. Вести перманентный набор и отсеивание кандидатов на работу, плановая работа по их обучению.
  16. Иметь планы краткосрочного и глобального развития компании. Регулярно их корректировать.
  17. Иметь соответствующую маркетинговую стратегию.
  18. Разработку вести на отдельном сервере для девелопмента, важна единственная схема поддержки и размещения ресурсов (сайтов в работе) на этом сервере. Трехуровневая схема размещения проекта в процессе разработки: девелопмент, превью, продакшен. Девелопмент и превью физически можно держать на одном офисном сервере. Все без исключения ресурсы dev-сервера должны требовать авторизации или быть доступными только из локальной сети и только в режиме только для чтения.
  19. Нужна единая концепция/схема предоставления уровней доступа к ресурсам: кто, к чему, откуда и даже когда. Например, обязательным должно быть ограничение доступа к репозитарию как минимум для новых работников как по отдельному проекту или его частям так и только из офиса, но открыть всем и каждому в компании доступ к общей базе знаний/wiki-ресурсу (под авторизацию). Иными словами, поощряя открытость, обмен информацией и опытом внутри компании, мы должны также думать о предотвращении утечки информации. В этой связи важно также донести до каждого разработчика понятие того, чей собственностью становиться код, написанный им для компании (но не переусердствовать!).
  20. Нужна единая схема резервного копирования для офиса и dev-сервера (резервное копирование для production — отдельная задача). В самом простом случае, когда разработка ведется исключительно на сервере, рабочие станции можно не бэкапить вообще и оставить этот вопрос на рассмотрение того, кто на ней работает.
  21. Единая политика работы с проприетарным программным обеспечением на рабочих станциях. Об установке каждой варезной программы (зачем и на какой термин) уведомление директора считать обязательным. Стремиться к использованию только лицензионных копий софта (да, покупать, если это нужно).
  22. Важно четкое разделение функций по управлению и разработке проекта. Программист фактически никогда не должен напрямую контактировать с клиентом, все задачи должны проходить через менеджера проекта. Стремиться к тому, чтобы разработчики не работали одновременно над несколькими проектами (насколько это возможно, конечно).


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

Вот, по возможности, коротко и все.
Tags:
Hubs:
+56
Comments 60
Comments Comments 60

Articles