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

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. Важно четкое разделение функций по управлению и разработке проекта. Программист фактически никогда не должен напрямую контактировать с клиентом, все задачи должны проходить через менеджера проекта. Стремиться к тому, чтобы разработчики не работали одновременно над несколькими проектами (насколько это возможно, конечно).


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

Вот, по возможности, коротко и все.
Метки:
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 60
  • +2
    > В то же время стоит работать с относительно бОльшим числом СУБД.
    Сколько времени работаю, кроме MySQL\sqllite пока что к сожалению ничего больше не требовалось.
    • 0
      ps за статью спасибо, поставил плюс ;)
      • 0
        спасибо, на самом деле действительно часто для веб-проектов и у нас MySQL. Но на относительно больших, самостоятельных (не CMS) проектах, стараемся склонить заказчика к другому выбору. В результате достаточно активно используем и PostgreSQL и даже Firebird. В прошлом занимались также поддержкой проекта на Oracle. Просто освоение новой СУБД по сравнению с освоением, например, новго фреймворка, «стоит» на несколько порядков дешевле, а кругозор (и резюме) расширяет существенно.
        • 0
          Вы склоняете заказчиков к использованию PostgreSQL вместо MySql ради «резюме», не имея представления принесёт ли ему это реальную пользу?

          Видимо действительно вы имеете высокий авторитет у них. Вы же не гоните им маркетинговую пургу типа «мускул вчерашний день, особенно после того как его приобрела оракл, надо от них отвязываться и потому надо переписать логику хранения на взаимодействие с PostgreSQL, тем более, что он с Oracle почти совместим»?

          Или реально сравниваете «за» и «против» двух разных SQL движков в конкретной ситуации? А про NoSQL задумывались? Это тоже «модно»!
          • 0
            А вопрос-то провокационный :). Нет, подобной «пурги» не гоним. Но когда проект достаточно большой и априори известно, что хостинг будет на отдельном сервере, Вы не считаете оправданным использование полноценной реляционной СУБД? MySQL, даже с InnoDB, не дотягивает. И, да — мне лично не нравится то, как развивается (точнее не развивается) MySQL после покупки его саном и, соответственно, теперь ораклом. Но, конечно, я далека от мысли о его скорой кончине ввиду его тотальной распространенности.
            А NoSQL пока не пробовали и даже не планируем пока — нет на чем :) — проект надо с соответствующим набором данных и — самое главное — экспериментальный.
    • +1
      Жестковато для 5-6 человек, имхо это уже 20+ нужна такая организация.
      Да даже и для более крупных студий имхо некоторые пункты лишние.
      К примеру, wiki и TDD. У не особо крупных студий вряд ли будут проекты требующие этой технологии, особенно учитывая web-специфику.
      • +3
        может быть и жестковато. Но по-другому не стоит :). на самом деле очень существенной является предпосылка о том, что наша задача в первую очередь строить не «студию» (с упором на дизайн), а все-таки контору по программировию (у нас дизайна в среднем около 5-10% по проекту, хотя есть, конечно, проекты и по 50%).
        Wiki — для внутреннего пользования просто незаменимая вещь.
        • +3
          Команды +20 рождаются из 3-5 человек. если на первоначальном этапе нет общих принципов и у каждого зоопарк, то на команде 20+ наложить такой устав будет ой как сложно.
          • +1
            Насчёт TDD не соглашусь. Даже в «студии» из одного человека она приносит ощутимую пользу. И, как не странно, именно в веб-специфике. Она даёт возможность простым способом (анализом текста) охватить полный (почти, если не трогать JS) поток выполнения. В случае, например, с GTK+ вы, извините за выражение, задолбаетесь его эмулировать стабами и моками.
          • +1
            Неплохо было бы в первый список еще добавить написание технического задания и оценка времени и стоимости выполнения работ. Как показывает практика этого как раз и не хватает для нормальной работы подобной команды. Так что наличие технического писателя в такой команде просто необходимо на мой взгляд, поскольку заказчики редко приходят с нормальной спецификацией (вообще практически не приходят).
            • 0
              тогда, действительно, народу нужно побольше. В идеале хотелось бы такими вещами нагрузить менеджера проекта.
            • +5
              На словах все красиво. На деле работал я в 3 вебстудиях — максимум 3 пункта из 22 использовались
              • 0
                ну что поделаеш, такова реальность. Но надо же к чему-то стремиться или по крайней мере понимать что делать-то.
              • 0
                Ни кто ни чего и ни кому не должен :) Реальность заставляет отступать от правил и принципов.
                А вообще ваша компания чем только не занимается, но при этом вы хотите разделить все полномочия среди сотрудников. У вас только дизайнера не хватает :)
                • 0
                  конечно правила на то и придуманы, чтобы от них отступать :). лучший вариант, если под все роли есть сотрудники, но дизайнера не всегда реально загрузить по полной, поэтому дизайнера, да, не хватает.
                • +1
                  Если что-то из этого выполняется у вас, не могли бы вы рассказать по пунктам по-подробнее свой опыт?
                  • +2
                    не все работает, конечно. в статье описан идеал: чего хотелось бы достичь.
                    Но многое работает, конечно. Из того, что не работает, это в первую очередь дисциплина ведения проекта, планирование и учет времени, не работает TDD. Многое работает не полностью, но такие вещи как, например, стандарт кодирования, контроль версий, трехуровневая разработка — все это работает.
                  • +2
                    В целом всё верно, на мой взгляд, но со вторым пунктом смею не согласиться. Важно не общее IDE, а поддержка ими функциональности, которая необходима. Как то: настройка общего стиля кодирования (форматирования), интеграция с СУБД/CVS/другое (ant, запуск/дебаггер локального сервера, если используется и т.д.).
                    Благо хороших IDE не мало, а привыкать к новому инструменту/ОС не всем хочется.
                    • 0
                      Поддержу, но замечу, что указанный пункт имеет право на жизнь. Но в одном случае только. Когда имеем унифицированное рабочее место. Т.е. теоретически любой разработчик может сесть за любое рабоче место и начать работу. Имхо, такое возможно только в больших студиях в условиях массового производства. А для небольшой студии вероятность близка к 0.
                      • 0
                        конечно важна поддержка функциональности. Но мы же не занимаемся разработкой драйверов и веб-разработкой. Исходим из того, что программируем только под web и даже больше — используем одну (ну максимум две) технологии (например php и perl).
                        Важно именно унифицированное рабочее место (как откомментировано ниже), имхо.
                        Прекасная штука — парное программирование (стоит время от времени практиковать) невозможна без единого IDE. Без единого IDE страдает процесс обучения.
                      • +2
                        С интересом прочел, но в целом есть огромное количество НО. В принципе все они сводятся к одой генеральной линии. В условиях небольшой студии они просто нереализуемые. Потому что их просто некому делать. Особенно это касается документации, обучения. Даже если такие вещи насаждаются сверху, то очень быстро стухают. Ну нежиснеспособны они в условиях небольшой студии, нежиснеспособны.

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

                        Кстати. 7 лет довольно приличный срок в нашей сфере. Сколько реально из указанных пунктов получилось реализовать у себя в полном объеме? Каких затрат это стоило, какой профит принесло? Т.е. я предлагаю не уходя в абстрактные размышления рассмотреть ваш конкретный случай.
                        • 0
                          реализуемые :). Конечно описан идеал — как хотелось бы работать.
                          Но даже если вы работаете один, многое из этого списка надо реализовать, имхо.
                          У нас работает не все: хуже всего с учетом и планированием. И еще с тестами. Но такие базвые вещи, как стандарт кодирования, как контроль версий, уровни доступа, внутренняя база знаний и вики — это все работает.
                          И работает, кстати, обучение — у нас почти все время 2-3 стажера (студенты), не все остаются, не все из оствшихся остаються на долго, но иначе работать вообще будет не с кем. Стараемся регулярно проводить семинары — это очень интересно, кстати.
                          • 0
                            Многое != все.

                            Кстати обучение может быть разным. Обучение работы с платформой на которых идет разработка — необходимость. А вот обучение более общим вещам уже не работает. Хороший специалист не знает, хороший препод. Как ни крути, но это разные специализации которые редко можно найти в одном человеке. А нанимать отдельного спеца тупо не выгодно.
                            • 0
                              да, конечно, но я же не сказала, что мы так работаем, я написала, что мы хотим так работать, что это важно.
                              С обучением, конечно, не все так просто. Но можно выделить 2 часа в конце дня раз в неделю, собраться всем за чаем у доски и послушать кого-то одного, потом подискутировать и разойтись по домам думать :). Имхо — это очень, очень важно. 2 года у нас не было семинаров (была серьезная причина) — очень все соскучились, возобновили. Все равно вы с коллегой где-то на кухне обсуждаете какие-то детали, например архитектуры (использовать синглтон, или нет например) — так имеет смысл вынести это на семинар в конце недели — у кого-то другие мысли конструктивные будут. И даже студент, который и слова то не знает такого, прочтет на доске о чем дискуссия будет, и тот википедию посмотрит и тоже чего-то там для себя из этого возьмет.
                              • 0
                                Если не секрет, сколько человек составляют «ядро» (время работы у вас от года), сколько человек всего? Есть ли какие то свои, студийные наработки. Есть ли архитектор вообще (человек, который решает, что использовать и в каком виде)?
                                • 0
                                  всего сейчас у нас работает 7 человек, из них «ядро» — 4.
                                  Решения по архитектуре проектов принимаются, как правило, коллегиально (2-3 чел).
                                  Свои наработки, конечно, же есть, есть даже идея выложить в open source один проект, но он требует подготовки и доработки пока. По существенным причинам (рождение ребенка) мы сильно притормозили, если не сказать вообще откатились назад за последние 2 года, но это временно, надеюсь. Не хочу, поэтому, называть здесь никаких URL.
                                  Из интересного нетипичного опыта у нас серьезные проекты на связке php+Firebird.
                                  • 0
                                    Хм… ребенок. Имхо, личные обстоятельства одно из участников влияющие на вектор развития проекта в целом это очень плохо. По крайне мере для проекта такого возраста наличие ключевых людей — потенциальный фактор который может все потопить.

                                    А со сторонними разработчиками сотрудничайте?
                                    • +1
                                      личные обстоятельства двоих ключевых участников :).
                                      конечно плохо. Но прект-то тоже «личный» до некоторой степени, и выхода-то другого нет.
                                      На счет сторонних разработчиков — нет, стараемя не привлекать. В первую очередь по причине ответственности за код и сопровождение.
                                      • 0
                                        Если «заставить» внешнего разработчика следовать всем правилам, то особых проблем быть не должно с сопровождением кода — следует стандартам оформления, использует стандартные инструменты, покрыт тестами, лежит в VCS и т. п.
                        • +3
                          работать, по возможности, с максимум СУБД — это путь в ад )
                          • 0
                            не соглашусь. максимум здесь не очень высок — выбор и так небольшой. Но освоение новой СУБД достаточно «дешево» — все-таки SQL и нормальную форму никто не отменял, а профит от этого относительно большой: вы расширяете рамки и работы и собственного понимания. Например на данный момент мы работаем все-то с тремя СУБД: MySQL, PostgreSQL и Firebird.
                          • 0
                            Спасибо, но вопрос. Пункт 18, что вы имели ввиду под «режимом только для чтения» и почему необходимо использовать именно его, а не полноценную версию продакшена, в качестве превью?
                            • 0
                              спасибо вам :).
                              Возможно я не до конца понятно изложила мысль. Пример из жизни:
                              у нас два (если не считать заказчиков) собственных сервера: одиин вннутренний, на котором ведется разработка и живут превью версии, другой — продакшен.
                              Речь о режиме доступа к внутреннему серверу: все ресурсы (проекты) закрыты под авторизацию: т.е. каждое изменение и даже каждый просмотр не анонимны. Исключением может быть сайт с базой знаний — он открыт изнутри (локальная сеть) но извне тоже требует авторизации.
                              Полноценная версия продакшена в качестве превью не годится, так как вам заказчик во-первых еще не за работу не заплатил, а если вы работаете над дополнительными фичами для уже существующего сайта, так сначала нужно «ок» от заказчика получить, а потом и на продакшем можно. Продакшен для превью не годится еще и потому, что превью часто «сырой» материал и ложить весь продакшен сервер из-за одного циклического редиректа, например, совсем не стоит.
                            • 0
                              Забыли упомянуть о «стандартизации» процедуры деплоя(выкладки) проектов на прод\стейджинг(превью) сервера.
                              Было бы отлично для всех членов команды использовать одни и те же инструменты(капистрано, фабрик и т.п.)
                              • 0
                                да, вы правы, спасибо — учтем на будущее :)
                              • +1
                                BugTracker + SVN (с разграничением доступа) + Wiki (простенький) + CRM (крайне простенький) — это Вам Redmine в помощь.

                                С разрешения автора :) список из статьи на стену повешу, буду партнера в него тыкать — «Смотри, это не я один такой, это умные люди придумали»
                                • 0
                                  спасибо за поддержку :),
                                  да, Redmine, конечно, хороший продукт, в качестве PMS для наших задач, возможно даже и лучший.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • 0
                                    спасибо, конечно учиться никогда не поздно.
                                    Согласна, что список неоднородный и его можно разбить на три по типу задач, но это дело вкуса.
                                  • 0
                                    > 2. Общее IDE и общий набор других инструментов (напр. программ для работы с базами данных). Мессенджер, конечно, каждый может использовать какой кому нравится, но работая по одной технологии нельзя держать зоопарк IDE даже если это и не стоит денег.

                                    Дальше читать не хочется. А если IDE напарника реализаует тот же функционал, что и ваше, то какая вам разница, чем он пишет код?
                                    • 0
                                      большая разница. Выше уже отвечала: когда вы работаете в группе и используете одну IDE, вам проще и легче показать и обьяснить другому члену команды, например, над чем вы работаете. Кроме того без единого IDE невозможно практиковать парное программирование. Иными словами выиграш в легкости передачи знаний в первую очередь.
                                      • 0
                                        Вы первая успели ответить (((
                                        • 0
                                          А кто определяет каким IDE будет пользоваться команда? Интересно, как вы будете уговаривать закостенелых вимеров или емаксеров пользоваться чем-нибудь типа NetBeans.
                                          • 0
                                            видите ли, когда вы устраиваетесь на работу, такие вещи должны быть оговорены. А кто определяет зависит от модели отношений в команде: может быть и единоличное решение, а можно и коллегиально. Новый человек должен подчиниться общим правилам, иначе не будет команды. Переход на новое IDE (сейчас у нас Eclipse) возможен, но здесь уже надо выслушать всех.
                                            • 0
                                              А вы можете назвать примеры компаний, где используется такая практика?
                                              • 0
                                                когда человек приходит на тестовый период в любую более-менее продвинутую команду и не желает подчиниться общим правилам, его просто-напросто не возьмут (если, конечно, не нанимают гуру у которого сами собираются учиться). Не возьмут не потому, что принципиальный или непрофессиональный, а потому что неуступчив и потенциально конфликтный. Я не назову вам конкретных имен компаний, но, поверьте, такие ньюансы выясняются еще до приема на постоянную работу и часто нет даже необходимости закреплять их формально соглашением на бумаге.
                                        • +1
                                          Примеры из личной жизни — NetBeans vs ZendStudio 8
                                          — форматирование отступов по умолчанию — 4 пробела vs tab.
                                          Возможно, это все настраиваемое, но из коробки у меня работало именно так.
                                          Очень неприятно знаете ли смотреть на код «елочкой», когда он добавляет какую-либо строчку посреди моей функции.
                                          — баги/особенности при работе с SVN у каждой IDE свои. Проще договориться что именно не стоит делать. У меня были случаи, когда NetBeans не мог провести svn update после какого-нибудь извращенного комита от ZS.

                                          И таких мелочей может быть очень много. Зачем это все испытывать на своей шкуре?
                                          Это при работе с напарником. При работе со стажером проще из памяти достать сочетание кнопок (расположение в меню) именно той IDE, которой пользуешься сам, чем подходить и разбираться.

                                          Кроме того, баги IDE при работе с SVN у каждой
                                          • 0
                                            не лучше ли устаканить code style guides, чем принуждать пользоваться неудобным инструментом?
                                        • 0
                                          Часть пунктов конечно не является истиной в последней инстанции, остальное, вроде бы очевидно, но некоторое до сих пор не ввели у себя. Лень матушка…
                                          • 0
                                            да, очевидные вещи, но иногда очень трудно кого в их очевидности убедить, к сожалению…
                                          • +2
                                            Все верно. У нас это называется процедуры. Есть по каждому блоку работы: проектирование, дизайн, верстка, программирование, тестирование и конечно менеджмент. Всего сотни пунктов, каждого заставляем использовать, а каждый этап проверяет тестер и менеджер проектов, смотрят соответствие этапа нормам качества прописанным в процедурах.

                                            Из этих пунктов используем где-то 17-18, у нас немного другая специфика и еще используем куча своих пунктов. Кстати, может кому интересно посмотреть на такие процедуры в форме чеклистов? Выложить на Хабре списками?
                                            • +1
                                              лично мне конечно же будет интересно!
                                              • 0
                                                Вам безусловно, делаем ведь одно и тоже и похожими способами :)
                                                • +1
                                                  + с удовольствием взял бы на вооружение
                                                  • +1
                                                    ок, подготовлю и выложу!
                                            • 0
                                              Большое спасибо, очень полезная информация :)
                                              • 0
                                                А не могли бы вы сказать в какой компании всё это используется? :)
                                                • 0
                                                  ВСЕ не используется нигде — это же идеал :).
                                                  Но мы стараемся :). Что работает на данный момент, а с чем — проблемы, уже овечала несколько раз выше: плохо работает планирование, частично менеджмент, тестирование. Если Вас действительно интересует название маленькой компании на Западной Украине, смотрите мой профайл, хотя по некоторым причинам он 2 года не обновлялся — будем исправляться.
                                              • 0
                                                >Стремиться к тому, чтобы разработчики не работали одновременно над несколькими проектами (насколько это возможно, конечно).

                                                Это возможно только в случае крупного или очень крупного проекта с таким количеством человек в команде. У вас их несколько одновременно, я так понимаю? Зачем тогда к этому стремиться? Или вы стремитесь (стратегически) к крупным проектам (и, как следствие, чтобы разработчики с ним одним и работали)?
                                                • 0
                                                  специфика компаний по веб-разработке такова, что в работе, как правило, одновременно относительно большое число опять же относительно небольших проектов. Сложно, конечно, в таких условиях работать конкретному человеку только над одним проектом, понятно. Но желательно все же стремиться к этому по той простой причине, что при частых переключениях между задачами существенно страдает эффективность работы. Поэтому я написала «насколько возможно». То, что можно все-таки сделать в таких условиях, это, например, оградить программиста от звонков и других прямых контактов (через мессенджер, например) с заказчиком, планировать работу из расчета, например, сегодня и завтра — один проект, послезавтра — другой, до обеда — один проект, послк обеда — другой, или, например, по однотипных задачах: настраиваем сегодня систему управления новостями для проекта 1 и 2, завтра — книгу отзывов и т.п.
                                                  И да, конечно, имеет смысл стремиться к крупным проектам, стратегически это выгодно.

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.