Организация рабочего процесса в команде на IT-проекте

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

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

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

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

    Никто не хотел брать на себя ответственность за проект (большой сервисный маркетплейс), текучка была страшная, заказчик просто рвал и метал. СЕО как-то подошел ко мне и сказал, что ты имеешь нужный опыт так вот тебе и карты в руки. Забирай проект себе. Облажаешься, проект закроем и всех выгоним. Получится, будет круто, тогда веди его и развивай, как считаешь нужным. В итоге я стал тимлидом на проекте и все легло на мои плечи.

    Первое, что я сделал — это разработал рабочий процесс с нуля, который соответствовал на тот момент моему видению, и написал должностную инструкцию для команды. Внедрять его было непросто. Но где-то в течении месяца все устаканилось, разработчики и клиент привыкли, и все пошло уже тихо и комфортно. Для того чтобы показать команде, что это не просто «буря в стакане», а реальный выход из ситуации, я взял на себя максимальный объем обязанностей, сняв неприятную рутину с команды.

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

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

    Поскольку на моем проекте это работает, то может быть кому-то это также сможет помочь. Итак, сам процесс, который помог нам спасти проект:

    Процесс работы команды на проекте «Мой любимый проект»

    a) Внутри командный процесс (между разработчиками)

    • Все задачи создаются в системе Jira
    • Каждая задача должна быть максимально описана, и выполнять строго одно действие
    • Любая фича, если она достаточно сложная, разбивается на много мелких тасок
    • Команда работает над фичами, как единой таской. Вначале делаем все вместе одну фичу, отдаем ее на тестирование, затем берем следующую.
    • Каждая задача маркируется, для бэкенда или фронтенда она
    • Есть типы тасок и багов. Нужно верно их указывать.
    • После выполнения задачи она переводится в статус ревью кода (при этом создается пулл реквест на своего коллегу)
    • Тот кто выполнял задачу сразу же трекает свое время для этой задачи
    • После проверки кода, ПР апрувится и после этого, тот, кто выполнял эту задачу, самостоятельно мержит ее в мастер ветку, после чего изменяет ее статус в готова для деплоя на дев сервер.
    • Все задачи, готовые к деплою на дев сервер, деплоятся тимлидом (его зона ответственности), иногда членом команды, если что-то срочное. После деплоя все таски с готова к деплою на дев переводятся в статус — готова к тестированию на деве
    • Все задачи тестирует заказчик
    • Когда заказчик протестировал задачу на деве, он переводит ее в статус готова для деплоя на прод
    • Для деплоя на прод мы имеем отдельную ветку, куда мержим мастер только перед деплоем
    • Если во время тестирования заказчик находит баги, то он возвращает задачу на доработку, устанавливая ей статус возвращена на доработку. Таким образом мы отделяем новые задачи от тех, которые не прошли тестирование
    • В итоге все задачи проходят путь от создания до завершения: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
    • Каждый разработчик тестирует свой код самостоятельно, в том числе и как пользователь сайта. Не допускается слитие ветки с основной, если доподлинно не известно, что код работает.
    • У каждой задачи есть приоритеты. Приоритеты расставляет либо заказчик, либо тимлид.
    • Разработчики в первую очередь выполняют приоритетные задачи.
    • Разработчики могут назначать задачи друг на друга, если были найдены разные баги в системе или одна задача состоит из работы нескольких специалистов.
    • Все задачи, которые создает заказчик, попадают к тимлиду, который их оценивает, и либо просит заказчика доработать либо назначает на одного из членов команды.
    • Все задачи, которые готовы к деплою на дев или прод, попадают также к тимлиду, который самостоятельно определяет, когда и как проводить деплой. После каждого деплоя тимлид (или член команды) должен уведомить заказчика об этом. А также сменить статусы для задач, на готово к тестированию на дев/прод.
    • Каждый день в одно и то же время (у нас это в 12.00) мы проводим митинг между всеми членами команды
    • Каждый на митинге отчитывается, включая тимлида, что он сделал вчера, что планирует делать сегодня. Что не получается и почему. Таким образом вся команда в курсе того, кто чем занимается и на каком этапе находится проект. Это дает нам возможность спрогнозировать и откорректировать, если нужно, наши эстимейты и дедлайны.
    • На митинге тимлид также озвучивает об всех изменениях в проекте и об уровне текущих багов, которые были найдены не заказчиком. Все баги разбираются и назначаются на каждого члена команды для их решения.
    • На митинге тимлид назначает на каждого задачи, учитывая текущую загруженность разработчиков, уровень их профессиональной подготовки, а также с учетом близости той или иной задачи к тому, чем занимается разработчик в данный момент.
    • На митинге тимлид вырабатывает общую стратегию по архитектуре и бизнес логике. После чего вся команда это обсуждает и принимает решение о внесении коррективов или принятии данной стратегии.
    • Каждый разработчик пишет код и строит алгоритмы самостоятельно в рамках единой архитектуры и бизнес логики. Каждый может выразить свое видение реализации, но насильно никто никого не заставляет делать только так, а не иначе. Каждое решение аргументируется. Если есть лучшее решение, но сейчас нет на него времени, то создается таска в жире, на будущий рефакторинг определенной части кода.
    • Когда разработчик взял в работу задачу, он переводит ее в статус разработки. Вся коммуникация по поводу уточнения задачи у заказчика ложится на плечи разработчика. Вопросы технического плана можно задавать тимлиду или коллегам.
    • Если разработчику не понятна суть задачи, а заказчик не смог толково ее разъяснить, то он приступает к следующей задаче. А текущую забирает тимлид и сам обсуждает ее с заказчиком.
    • Каждый день разработчик должен в чате клиента писать о том, над какими задачами он работал вчера и над какими задачами будет работать сегодня
    • Рабочий процесс происходит по скраму. Все разбито на спринты. Каждый спринт длится две недели.
    • Спринты создает, наполняет и закрывает тимлид.
    • Если проект имеет строгие дедлайны, то стараемся примерно заэстимейтить все таски. И собираем из них спринт. Если заказчик пытается в спринт добавить еще задачи, то мы тогда выставляем приоритеты, и какие-то другие задачи переносим на следующий спринт.

    б) Процесс работы с заказчиком

    • Каждый разработчик может и должен коммуницировать с заказчиком
    • Нельзя заказчику позволять навязывать свои правила игры. Нужно в вежливой и дружелюбной манере дать понять заказчику, что мы специалисты в своем деле, и только мы должны выстраивать процессы работы и вовлекать в них заказчика
    • Необходимо, в идеале, прежде чем приступать к реализации какого-либо функционала, создать блок-схему всего логического процесса для фичи (воркфлоу). И отправить ее на подтверждение заказчику. Это касается только сложного и не очевидного функционала, например, платежная система, система уведомлений и т.д. Это позволит более точно понять, что именно нужно заказчику, сохранить документацию к фиче, а также застраховать себя от того, что заказчик может в будущем сказать, что мы сделали не то, что он просил.
    • Все диаграммы/блок-схемы/логику и т.д. мы сохраняем в Конфлюенсе/Жире, где просим заказчика в комментариях подтвердить правильность будущей реализации.
    • Мы стараемся не грузить заказчика техническими подробностями. Если нам нужно понимание того, как заказчик хочет, то рисуем примитивные алгоритмы в виде блок-схемы, которые заказчик может понять и сам все исправить/доработать.
    • Если заказчик находит баг в проекте, то мы просим очень подробно расписать его в Жире. При каких обстоятельствах он произошел, когда, какую последовательность действий осуществлял заказчик при тестировании. Просим прикреплять скриншоты.
    • Мы стараемся каждый день, максимум через день делать деплой на дев сервер. Заказчик тогда начинает тестировать функционал и проект не простаивает. При этом это является маркером для заказчика, что проект находится в полной разработке и никто не рассказывает ему сказки.
    • Очень часто бывает так, что заказчик не до конца понимает, что ему вообще нужно. Так как создает новый для себя бизнес, с еще не отлаженными процессами. Поэтому очень частым случаем бывает ситуация, когда мы выбрасываем в мусорник целые куски кода и перекраиваем логику приложения. Из этого вытекает, что не стоит абсолютно все покрывать тестами. Есть смысл покрывать тестами только критически важный функционал и то с оговорками.
    • Бывают ситуации, когда команда понимает, что мы не вписываемся в дедлайны. Тогда мы проводим быстрый аудит по задачам, и тут же сообщаем об этом заказчику. В качестве выхода из ситуации мы предлагаем запускать в срок важный и критический функционал, а остальное оставить на пострелиз.
    • Если заказчик начинает придумывать разные задачи из головы, начинает фантазировать и объяснять на пальцах, то мы просим его предоставить нам макет страницы и флоу с логикой, которая должна полностью описать поведение всего макета и его элементов.
    • Перед тем, как взять в работу любую задачу, мы должны удостоверится, что эта фича входила в условия нашего договора/контракта. Если это новая фича, которая выходит за пределы наших первоначальных договоренностей, то мы обязательно должны заэстимейтить эту фичу ((примерное время выполнения + 30%) х 2) и указать заказчику, что у нас уйдет столько-то времени на нее, плюс дедлайн смещается на время эстимейта помноженное на два. Сделаем задачу быстрее — замечательно, все от этого только выиграют. Если нет, то мы подстраховались.

    в) Что мы не приемлем в команде:

    • Необязательность, несобранность, забывчивость
    • „Кормление завтраками“. Если не можешь выполнить задачу, не знаешь как, то об этом нужно тут же уведомлять тимлида, а не ждать до последнего.
    • Бровады и похвальбы от человека, который не доказал еще делом свои возможности и профессионализм. Если доказал, то можно, в рамках приличия :)
    • Обман в любых его проявлениях. Если задача не выполнена, то не стоит менять ее статус на выполненную и писать в чате клиента, что она готова. Сломался компьютер, слетела система, собака погрызла ноутбук — все это недопустимо. Если происходит реальный форс-мажор, то тимлид тут же должен быть уведомлен.
    • Когда специалист все время в офлайне и к нему сложно достучаться в рабочее время.
    • Токсичность в команде не допускается! Если кто-то с чем-то не согласен, то все вместе собираются на митинг и это обсуждают и решают.



    И еще ряд вопросов/тезисов, которые я иногда задаю своему заказчику, чтобы снять все недопонимания:

    1. Какие у вас критерии качества?
    2. Как вы определяете есть ли в проекте проблемы или нет?
    3. Нарушая все наши рекомендации и советы по изменению/улучшению системы, все риски несете только вы
    4. Любые мажорные изменения проекта (например, всевозможные экста флоу) будут приводить к возможному появлению багов (которые мы будем, естественно, фиксить)
    5. Невозможно в течении пары минут понять, что за проблема произошла на проекте, а тем более тут же ее пофиксить
    6. Мы работаем по конкретному продукт флоу (Таски в Жира — Разработка — Тестирование — Деплой ). А значит мы не может реагировать на весь поток просьб и жалоб в чате
    7. Программисты являются именно программистами, а не профессиональными тестировщиками, и не могут обеспечить надлежащее качество тестирования проекта
    8. Ответственность за конечное тестирование и прием задач на проде лежит полностью на вас
    9. Если мы уже взяли в работу задачу, то не можем сразу же переключаться на другие, пока не доделаем текущую (иначе это приводит к еще большим багам и увеличению времени разработки)
    10. Людей в команде стало меньше (по причине отпусков или болезней), а работы стало больше и мы физически не успеем реагировать на все, что вы хотите
    11. Просьба с вашей стороны сделать деплой на прод без протестированных задач на деве — это только ваши риски, а не разработчиков
    12. Когда вы ставите нечеткие задачи, без корректного флоу, без макетов дизайна, то это требуюет от нас намного больших усилий и сроков реализации, так как нам вместо вас приходиться делать дополнительный объем работы
    13. Любые таски по багам, без детального описания их возникновения и скриншотов, не дают нам возможности понять, что пошло не так, и как нам сэмитировать этот баг
    14. Проект требует постоянной доработки и улучшений для повышения производительности и безопасности. Поэтому команда тратит часть своего времени на эти улучшения
    15. По причине того, что у нас бывают переработки по часам (срочные фиксы), то мы должны их компенсировать в другие дни

    Как правило, заказчик сразу понимает, что не так все просто в разработке софта, и одного желания тут явно недостаточно.

    В общем это все. За кадром оставляю множество переговоров и первоначальную отладку всех процессов, но в результате все наладилось. Могу сказать, что этот процесс стал для нас некой «Серебряной пулей». Новые люди, которые приходили в проект, могли уже сразу впрягаться в работу с первого дня, так как все процессы описаны, а документация и архитектура в виде диаграм сразу давала представление о том, чем мы тут все занимаемся.

    P. S. Хочу уточнить, что на нашей стороне проджект менеджера нет. Он есть на стороне заказчика. Совсем не технарь. Проект европейский. Вся коммуникация только на английском.

    Всем удачи на проектах. Не выгорайте и постарайтесь улучшать свои процессы.

    Исходник в моем блоге.

    Средняя зарплата в IT

    110 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 8 477 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 60

      +3
      Каждый разработчик может и должен коммуницировать с заказчиком

      Это пять…
        –1
        Это касается сугубо моего проекта и видения. До этого каждый сам себе что-то «понимал» из задачи в два абзаца и пилил совсем не то, что было нужно заказчику. Прожект менеджера на проекте нет (с нашей стороны), в качестве него выступает член комады со стороны заказчика. Прокт европейский, все только на английском, естественно. Процент недопонимания друг друга немаленький.
          0
          оу, извиняюсь. Вот это важное уточнение: «Прожект менеджера на проекте нет (с нашей стороны)».
          Я изначально и хотел спросить ещё, а чем же у Вас стали заниматься PM?

          Думаю, что неплохо было бы вынести это уточнение в саму статью.

          Спасибо за ответ!
            0
            Да, пожалуй добавлю. Спасибо.
          +1

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

          0

          "Когда заказчик протестировал задачу на деве, он переводит ее в статус готова для деплоя на прод"
          Погодите, а заказчик сам копается в репозитории и разбирается в ветках? Или есть какой-то софт, оборачивающий весь этот процесс во что-то приятное и понятное заказчичу? Тогда расскажите, пожалуйста, что за софт используется

            0
            Да не, скорее всего, ему разворачивают на тестовом сервере и он просто смотрит, что получилось. У них во флоу это называется QA on Dev. Только, я бы не назвал проверку со стороны заказчика QA. Скорее, просто тестирование на соответствие ожиданиям. Но может я чего-то не знаю)
              0

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

              0
              Мы используем систему управления проектами Atlassian Jira. Все задачи вместе со статусами ведуться в этой системе. В ней же и настроено флоу для работы. Клиент создает в ней задачи и контролирует их там.
                0

                Было на многих проектах проще: разработчик и/или CI разбираются с ветками и деплоят на дев окружение, меняют статус задачи на что-то вроде "ready to acceptance" и, опционально, отписываются заказчику в задаче.


                Варианты:


                • ветки задачи мерджатся в общую дев/стейджинг/препрод ветку, которая после каждого мерджа деплоится на дев/стейджинг/препрод среду
                • под задачу динамически создаётся отдельная среда из веток задачи со своим базовым доменом типа task-123.dev.example.com и в общую ветку мерджится только после приёмки
                • у каждого разработчика своя среда, которую он сам готовит к приёмке
                • у каждого тестировщика (включая стейкхолдеров заказчика) своя среда, переключение которой на ветки задачи максимально автоматизировано до кнопки/ссылки в джире или типа того.
                +1
                Звучит так, как будто компания экономит на бизнес/системном аналитике, PM'e и тестировщиках и размазывает эти обязанности по разработчикам.
                  +1
                  На аутсорсе это частое явление. Заказчики, в основном, не хотят оплачивать наемный менеджмент со стороны подрядчика (ПМ, аналитики и т.д.). Им нужны только технари, а менеджмент они сами предоставляют. Порой это не самые квалифицированные специалисты, именно в областе ИТ, но они хорошо разбираются в бизнес вопросах и в том, что именно им нужно. Поэтому, когда в такой проект кидают только программистов без опыта управления и общения напрямую с заказчикамы, то проекты, как правило, проваливаются. И это, к сожалению, объективная реальность. Именно поэтому, многие компании требуют знание английского на хорошем уровне и наличие развитых софт скилов. Но это уже другая история ))
                    0
                    Поэтому, когда в такой проект кидают только программистов без опыта управления и общения напрямую с заказчикамы, то проекты, как правило, проваливаются. И

                    Когда кидают туда программистов с опытом разработки только в атмосфере микроменеджмента и/или условного "водопада", по чёткому ТЗ. "Нулевой" джун может в итоге больше сделать для проекта, чем убеленный таким опытом сеньор. Просто потому что джун будет постоянно переспрашивать постановщика задачи, других разработчиков и т. п., а правильно ли он его понял, показывать промежуточные шаги и т. п., а сеньор "пропадёт" на неделю и принесёт "готовую" задачу" в чётком в соответствии с придуманным им самим ТЗ, потому что без ТЗ он не может, а задача в джтре не ТЗ, а какая-нибудь юзер-стори

                  –1
                  Мда… Много умных слов, но, к сожалению, мало смысла в них.
                  Это публикация написана для самопроверки понимания процесса, и чтобы запиарить себя и линк на блог. Знать значение слов «Jira», «эстимейт», «дедлайн» — это не значит понимать то, что пишите.
                  Более того, данный подход полностью нерабочий, т.к. здесь отсутствуют основные звенья, поддерживающие даже базовый процесс разработки.
                  Можно говорить по каждому пункту крайне много…

                  Скажу про этот:
                  Приоритеты расставляет либо заказчик, либо тимлид.
                  Да-чего там… Без разницы… Поменялся приоритет с зависимой задачи и… Ах-да! Обсуждения же ежедневные есть! Ставим хором приоритет одной задачи всю неделю/две, гоняя эту задачу по всем веткам и этапам процесса разработки так, чтобы всё отметить и ничего не упустить?
                  Спросите:
                  Зачем, это ж вроде просто?!
                  Отвечу сразу:
                  И я вот говорю: зачем так делать? Зачем мешать работать архитектуре проекта (и разработчикам!) самостоятельно и без каких-либо указаний со стороны тимлида или заказчика?
                  Запомните: Каждый разработчик в проекте должен знать только две вещи: что нужно сделать, чтобы заработал базовый функционал и что нужно будет добавить после того, как он сделает базовый функционал (все приоритеты по своим задачам ставит именно сам разработчик этих задач). Каждый разработчик — свой уровень/блок/функционал в архитектуре проекта.
                  1. Никаких приоритетов!!! Если появляются приоритеты в задачах — это уже не разработка, а балаган.
                  2. Не нужно засорять разработчикам мозг доп. задачами, которые не должны быть в предстоящем релизе.
                  3. Не нужно забирать у них данные им ранее задачи в работу и ссылаться так: «Ой, это не я, это заказчик так захотел». Это косяк именно тимлида, а не разработчика.

                  PS: И так, можно тут по каждому пункту целую статью писать…
                    0

                    Согласен частично разве что со вторым пунктом. Так что пишите )

                      +1
                      Когда разработчик не знает ничего, кроме своей задачи, согласно описания в JIRA, имеет цену — формальное выполнение и очевидные ошибки при полном соблюдении формальных требований.
                      0
                      Прочитал статью и оно конечно возможно и стало лучше чем было, но я бы так работать точно не стал.

                      Тимлид однозначный bus factor и без него работа встанет. У вс тимлиды не болеют и в отпускa не ходят? Разработчики могут назначать друг-другу задачи? Штатного QA вообще нет? Приоритеты могут меняться в любой момент? Все всегда вместе пилят одну фичу даже если это создаёт лишние проблемы с мёрджем? Подробные отчёты на ежедневных митингах? Все разработчики должны сами добывать инфу у клиента? Бррр… Спасибо, но точно без меня :)
                        0

                        А мне в целом нравится, кроме бас-фактора

                          0
                          Не знаю. На мой взгляд однозначно должны быть и нормальные тестеры.

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

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

                            Нормальные тестеры предполагаются на стороне заказчика, либо заказчик берёт на себя все эти риски.


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


                            Смотря что называть "заставлять". Я противник того, чтобы в команде работали люди, для которых правила команды не писаны. Если мне правила принципиально не подходят и продвинуть подходящие мне не получается, то я просто ухожу. От других ожидаю того же. Если решили, что каждый по своей задаче коммуницирует с заказчиком/стейкхолдером сам, и незаметно делегировать это коллеге не получается, то должны коммуницировать сами. Можно дополнительно мотивировать, привязав повышения к отзывам от заказчика. Отзыв наравне с остальными вряд ли получится получить, если все коммуникации ограничиваются done, fixed, fixed, fixed

                              0
                              Нормальные тестеры предполагаются на стороне заказчика, либо заказчик берёт на себя все эти риски.

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

                              Главное в этих митингах: какие проблемы были, есть или могут быть и кто может с ними помочь.

                              Ну да. И этим вполне себе можно и ограничится. Зачем нужно остальное?

                              Смотря что называть «заставлять».

                              Это значит ставить людей перед выбором: либо делай так, либо увольняйся. Причём в случае с задачами, которые в общем-то не являются чем-то для них стандартным и обычным. Причём не в момент устройства на работу, а когда тебя уже взяли на совсем других условиях.
                                0
                                В данном случае я вижу что тесты и ответственность за них просто свалили на разработчиков.
                                Все задачи тестирует заказчик
                                Когда заказчик протестировал задачу на деве, он переводит ее в статус готова для деплоя на прод
                                Каждый разработчик тестирует свой код самостоятельно, в том числе и как пользователь сайта. Не допускается слитие ветки с основной, если доподлинно не известно, что код работает.

                                Где тут ответственность свалили? Мы как-то очень по разному понимаем последнее предложение? Для меня оно означает, что нужно хотя бы проверить что в простейших сценариях код не падает.


                                Ну да. И этим вполне себе можно и ограничится. Зачем нужно остальное?

                                Для поддержания в команде общего понимания где мы сейчас, сколько прошли и сколько осталось.


                                Причём в случае с задачами, которые в общем-то не являются чем-то для них стандартным и обычным.

                                Ну как сказать, не являются. Вроде даже в ПТУ на программиста учат принимать участие в сборе требований и составлению ТЗ. Ну и по опыту работы в малом ИТ-бизнесе или в среднем не ИТ, нормальное ТЗ — исключение, а не правило.


                                Причём не в момент устройства на работу, а когда тебя уже взяли на совсем других условиях.

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

                                  0
                                  Где тут ответственность свалили?

                                  А это что:
                                  Каждый разработчик тестирует свой код самостоятельно, в том числе и как пользователь сайта. Не допускается слитие ветки с основной, если доподлинно не известно, что код работает.


                                  Для поддержания в команде общего понимания где мы сейчас, сколько прошли и сколько осталось.

                                  Этого нельзя добиться более простым способом? Банальным burn down'om например? Или просто тем что каждый может посмотреть на статусы и общую ситуацию в трэкере? Зачем кучу времени тратить на «я сделал таск 1 и таск 2 и таск 3 и ....»?

                                  Ну как сказать, не являются.

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

                                  Вроде даже в ПТУ на программиста учат принимать участие в сборе требований и составлению ТЗ.

                                  И даже это не означает умение общаться с заказчиком.
                                    0
                                    Все что написано в статье — это не догма! А всего-навсего частный случай в моей команде. И людей я подбирал именно тех, которые все это могут. Оплата труда вполне сответствующая. Никого выгонять не нужно. В аутсорсинговых компаниях ведется много параллельных проектов. Люди могут мигрировать с проекта в проект. А еще есть оплачиваемый бенч.

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

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

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

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

                                    Это все ИМХО.
                                      0
                                      И людей я подбирал именно тех, которые все это могут. Оплата труда вполне сответствующая. Никого выгонять не нужно

                                      Извините, а это вот что тогда было:
                                      Кто-то в старой команде не захотел так работать и ушел

                                      ?

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

                                      Ну здорово. Вот пусть они, то есть те кто это хочет и может, и общаются с заказчиками. Можно им даже за это больше платить. Зачем вот прямо всех заставлять это делать?

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

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

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

                                      Но при этом совершенно спокойно можно создать «прослойку» между программистами и заказчиком и это великолепно работает в куче фирм. И да, это прослойка может состоять в том числе и из программистов, которые умеют это делать. Например на мой взгляд вполне себе хватит если в команде этим занимаются тимлид и один-два сениора. Или ПО/ПМ. То есть нет какой-то необходимости чтобы этим занимались прямо все разработчики.
                                        0
                                        можно создать «прослойку» между программистами и заказчиком и это великолепно работает в куче фирм.

                                        На моём опыте, пресловутое time-to-market в этих фирмах больше чем в тех, где программисты общаются с постановщиками задач напрямую. Даже просто задержки на коммуникации снижают скорость разработки, не говоря об эффекте испорченного телефона.

                                          0
                                          Может быть. Но при этом я уверен что каких-то других проблем при этом меньше. Или вы так не думаете? :)
                                            0

                                            Разве что меньше проблем доходит до заказчика. Типа разработчик обматерит заказчика в лице ПМа, а не лично.

                                              0
                                              Или разработчик что-то неправильно поймёт потому что не разбирается в нюансах отрасли и/или бизнес-процессов заказчика. Или разработчик на общение с заказчиком будет тратить очень много времени. Или разработчик что-то не то ляпнет заказчику. И так далее и тому подобное.

                                              То есть по моему опыту среднего разработчика к заказчику напрямую пускать не стоит. Как минимум без присмотра точно нет.
                                                0

                                                С присмотром или без — это детали имплементации процесса.


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

                                      0
                                      А это что:

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


                                      Но нельзя ожидать таких умений от каждого разработчика.

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

                                        0
                                        Для меня это минимально необходимые проверки. Написал код — проверил, что он вообще не ложит сервер в основных сценариях.

                                        Угу, и если заказчик всё-таки нашёл баги, то никто не виноват?

                                        Вроде как это базовые компетенции программиста, определённые даже в профессиональных стандартах.

                                        Ну у нас такого нет, поэтому мне интересно о чём речь. Не подскажете конкретнее что там и где определено и как это проверяется/учитывается при приёме на работу. Ну то есть там вакансии тоже по стандарту расписаны или как?
                                          0
                                          Угу, и если заказчик всё-таки нашёл баги, то никто не виноват?

                                          А если штатные тестировщики нашли баги, то кто виноват?


                                          Ну у нас такого нет

                                          У вас это где, если не секрет?

                                            0
                                            А если штатные тестировщики нашли баги, то кто виноват?

                                            «Штатные тестировщики». Потому что это их зона ответственности.

                                            У вас это где, если не секрет?

                                            Германия, да и пожалуй большая часть ЕС. Наверняка ещё где-то.

                                            Так как конкретно это всё определено в профстандартах и вакансиях на работу? Мне действительно интересно.
                                              0
                                              «Штатные тестировщики». Потому что это их зона ответственности.

                                              Значит заказчик виноват. Потому что это его зона ответственности при такой работе.


                                              Так как конкретно это всё определено в профстандартах...?

                                              Российский, например https://classinform.ru/profstandarty/06.001-programmist.html. Можно по странице поискать по слову "согласование"


                                              В вакансиях обічно такое не пишут, но в сильно бюрократизированніх организациях требуют соответствие образования — диплом предполагает наличие соответствующих знаний и хотя бы базовых навыков

                                                0
                                                Значит заказчик виноват. Потому что это его зона ответственности при такой работе.

                                                То есть в такой ситуации для программиста не будет никаких последствий? Почему-то я в это не верю…

                                                Российский, например classinform.ru/profstandarty/06.001-programmist.html. Можно по странице поискать по слову «согласование»

                                                Я там нахожу только «согласование сроков». Я не так ищу?

                                                В вакансиях обічно такое не пишут

                                                И откуда тогда я должен знать что конкретно от меня требуется? Особенно если в вакансии написано «разработчик» или вообще «software developer»? :)
                                                  0
                                                  То есть в такой ситуации для программиста не будет никаких последствий? Почему-то я в это не верю…

                                                  Когда работал так, то последствия были обычные для нахождения багов. Не важно кто и когда нашёл.


                                                  Я там нахожу только «согласование сроков». Я не так ищу?

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


                                                  И откуда тогда я должен знать что конкретно от меня требуется?

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

                                                    0
                                                    Когда работал так, то последствия были обычные для нахождения багов. Не важно кто и когда нашёл.

                                                    То есть никаких? Или какие?

                                                    В хорошей вакансии прописано что-то вроде «участие в сборе требований» или «непосредственное взаимодействие с представителями заказчика».

                                                    Тогда почему в данном конкретном случае кто-то ушёл когда «поменялись правила»? :)
                                                      +1
                                                      Тогда почему в данном конкретном случае кто-то ушёл когда «поменялись правила»? :)

                                                      Потому что многие люди не хотят/не могут выходить из зоны своего комфорта. Но это не проблемы бизнеса, а этих людей. Для того, чтобы что-то найти (деньги, людей, процессы, и т.д.), то нужно это искать. А тот, кому хорошо и так, без этой вечной суеты, остаются за бортом возможностей. Люди ушли из проекта. Кто-то на бенч, кто-то в другие проекты. Кого-то потом уволили, после пары негативных отзывов от другого заказчика (вообще очень частый случай). На аутсорсе «отсидеться» не получится — это я гарантирую на 100%.
                                                        0
                                                        Потому что многие люди не хотят/не могут выходить из зоны своего комфорта.

                                                        А давайте наоборот: вот нанялся к вам человек разработчиком с условием что он будет общаться с заказчиками. А потом через год передумал и заявил «я больше так делать не буду и это не моя проблема, а вам пожалуй стоит выйти из вашей зоны комфорта». Как вы на это отреагируете?

                                                        То есть ещё раз: если такие условия ставились заранее и человек на них согласился когда устраивался на работу, то на мой взгляд это не проблема и такой подход вполне легитимен. А вот менять правила игры по ходу это на мой взгляд не дело.

                                                        Но это не проблемы бизнеса, а этих людей.

                                                        Учитывая нехватку кадров и высокие зарплаты на данный конкретный момент это как раз таки скорее проблема бизнеса.
                                                          0
                                                          Мне кажется, что вы очень сильно переоцениваете ситуацию на рынке труда. Наниматели из Европы и США мониторят весь мир, а не только страны бывшего Советского Союза. И наших программистов нанимают не потому, что они такие гениальные, а потому что они дешевые. И нанимают в основном гребцов, так как у них есть свой менеджмент и лиды.

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

                                                          А если, вдруг, какой-то компании позарез нужен будет высококвалифицированный специалист здесь и сейчас, то искать на улице никто не будет. Его схантят с другой работы с зарплатой + 1 тыс. долларов, вот и всех делов-то.
                                                            0
                                                            Мне кажется, что вы очень сильно переоцениваете ситуацию на рынке труда.

                                                            Наверное именно из-за того что я её переоцениваю у нас на фриме постоянно открытые вакансии и мне постоянно приходят предложения от каких-то там HR агенств. А стоит мне выставить своё резюме на каком-нибудь портале, так за пару часов почтовый ящик завален. И ладно бы я был каким-нибудь супер-пупер гением…

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

                                                            Я не «наш». Ну или не «ваш» :)

                                                            Отвечая на ваш вопрос, то такого спеца просто выгонят на мороз.

                                                            То есть у других вы такое поведение не приветствуете, но при этом сами себя так ведёте…
                                                              0
                                                              Если вы мне объясните, что именно вы мне пытаетесь доказать, то мне будет проще давать вам более конкретные ответы по теме.
                                                                0

                                                                Я вам пытаюсь объяснить что отдельные аспекты описаного вами поведения я не считаю этически корректными.


                                                                Ну или если по простому, то то что вы местами делаете в простонародье называется "дерьмовый работодатель".

                                                                  +1
                                                                  Ну, во-первых, я не работодатель. Работодатель — это аутсорсинговая компания и заказчик, который оплачивает весь этот «праздник жизни». А во-вторых — я всего-навсего описал рабочий процесс, который никому не навязываю. Я могу снять людей с проекта, но уволить я их не могу.

                                                                  Ну и последний момент: «Нет такой профессии, как хороший парень». Если сотруднику что-то не нравится, то он вправе найти более подходящее место работы. Тут уже вопрос в том, что такие люди не будут получать высоких зарплат. А тот, кто хочет иметь высокий доход, тот будет идти в ногу с заказчиком, ради заказчика, и для заказчика и соответственно, проекта. По другому не бывает.
                                                                    0

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


                                                                    Ну и как бы те люди которые от вас ушли они остались без работы? А те, кого вы взяли на их место, получают больше денег илт меньше?

                                                            0
                                                            А вот менять правила игры по ходу это на мой взгляд не дело.

                                                            Нормальная ситуация, настолько нормальная, что даже в трудовом законодательстве прописана. Особенно если декларируются agile подходы изначально, где изменения правил игры неотъемлемая часть процессов. Нет изменений — нет agile.

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

                                                                А тут вы думаете другая ситуация? На улицу в мороз перед Новым годом? )

                                                                  0
                                                                  Ну если судить по тому что я успел прочитать, то да, я думаю тут скорее другая ситуация. Может и не на мороз перед НГ, но скорее ближе к этомy чем какие-нибудь отступные в размер полугодовой зарплаты.
                                                                    0

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

                                                                      0
                                                                      И это я тоже не считаю правильным поведением.

                                                                      Понимаете это же всегда банальное «как аукнется так и откликнется». И если фирмы начинают себя вести вот так, то и люди в ответ тоже. И в результате все в проигрыше.
                                                                        0

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

                                                          0
                                                          То есть никаких? Или какие?

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


                                                          Тогда почему в данном конкретном случае кто-то ушёл когда «поменялись правила»? :)

                                                          Некоторые компании или, скорее, нанимающие менеджеры используют в вакансиях фразы типа "общение только внутри команды" или "общение только с лидом/ПМ" как продающие для людей определённого склада, с которыми им эффективней работать. Пришёл новый менеджер, изменил условия и работа перестаёт быть привлекательной. Человек может и может делать что-то от настройки локального дев-окружения до переговоров с заказчиком, но не хочет. И есть места, где он этого может не делать. Вот и уходит туда. А кто-то другой наоборот, целенаправленно идёт туда, где будет общаться с бизнесом напрямую.

                              +1
                              Немного критики. Надеюсь конструктивной :)

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

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

                              Максимально описана, это как? Как по мне, в идеале это прямо код или в крайнем слечае псевдокод. Но я сильно подозреваю, что зачастую в описании используются подразумеваемые особенности (но которые в коде все равно отражаются), типа если добавляем кнопку, то не указываем, что вид у нее стандартный для проекта и подобное.

                              Любая фича, если она достаточно сложная, разбивается на много мелких тасок

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

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

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

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

                              Непонятны еще такие моменты:
                              Каждый на митинге отчитывается, включая тимлида, что он сделал вчера, что планирует делать сегодня.

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

                              Разработчики в первую очередь выполняют приоритетные задачи.

                              На митинге тимлид назначает на каждого задачи

                              Так кто назначает задачи? Каждый сам планирует что делать? Может раздает тимлид? А вообще есть ли в этом смысл, если нужно брать следующую по приоритету? В общем пункты друг другу немного противоречат.

                              Тот кто выполнял задачу сразу же трекает свое время для этой задачи

                              Каждый на митинге отчитывается, включая тимлида, что он сделал вчера, что планирует делать сегодня.

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

                              Если все трекается, то какой смысл говорить о том, что сделано и делается? Кому интересно, может открыть жиру и посмотреть, кому не интересно, тот мимо ушей пропустит (вот я, к примеру, всегда так делаю :) ) Ну и зачем разрабу отписывать в чате чего сделано? Бота нельзя настроить, если уж заказчик по каким-то причинам не может пользоваться жирой?
                                +1
                                Спасибо за ответ, попробую все прояснить более детально:
                                Максимально описана, это как? Как по мне, в идеале это прямо код или в крайнем слечае псевдокод. Но я сильно подозреваю, что зачастую в описании используются подразумеваемые особенности (но которые в коде все равно отражаются), типа если добавляем кнопку, то не указываем, что вид у нее стандартный для проекта и подобное.

                                Например, есть задача: отправку напоминанию клиенту, что нужно оплатить инвойс. Обычная постановка задачи так и звучит, что нужно сделать такую фичу. И тут возникает ряд вопросов. А отправлять напоминание нужно один раз или много? Если много, то с каким промежутком? А напоминать через мыло или еще и через СМС, вебсокеты и т.д.? А если клиент так и не заплатил, то что делать с этим, до конца дней присылать уведомления? А если нужно останоить рассылку, то при каких условиях? Без ответов на эти вопросы не возможно четко выполнить поставленную задачу. Вот поэтому и нужно подробно описать заказчику, что нужно делать. Если он этого не может сделать или толково объяснить, то я созваниваюсь с заказчиком и мы все это обсуждаем. Я создаю флоу и кидаю на утверждение.

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

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

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

                                Изначально на проекте было 8 человек. 1 ПМ/аналитик, 1 QA 4 бэкендера и 2 фронтендера. В итоге сроки посрочены, работа топталась на месте, все искали виновных, проект замер. Клиент стал зверствовать и почти всех поувольнял. В итоге, осталось всего 3 человека. Я (пишу и бэк и фронт, выполняю роль и системного аналитика и архитектора, скрам тоже на мне), один бэкендер сениор и один фронтендер сениор. Перформанс увеличился раз в 10! Клиент теперь спокоен, как удав. Затраты уменьшились в разы, скорость увеличилась на порядок.

                                Так кто назначает задачи? Каждый сам планирует что делать? Может раздает тимлид? А вообще есть ли в этом смысл, если нужно брать следующую по приоритету? В общем пункты друг другу немного противоречат.

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

                                Если все трекается, то какой смысл говорить о том, что сделано и делается? Кому интересно, может открыть жиру и посмотреть, кому не интересно, тот мимо ушей пропустит (вот я, к примеру, всегда так делаю :) ) Ну и зачем разрабу отписывать в чате чего сделано? Бота нельзя настроить, если уж заказчик по каким-то причинам не может пользоваться жирой?

                                Жира — это всего-лишь инструмент с кучей флагов. На каждом митинге мы всегда в курсе всего процесса работы. Фронтендер четко знает, что творится на бэке. Бекендер все знает о фронте. Так как на фронте юзается Реакт, то сам фронтендер в отрыве от бэкенда ничего не сможет сделать и наоборот. Создание одной конкреной фичи — это когда и бэк и фронт синхронно работают над одной задачей, чтобы превратить это в законченный кусок функционала. А так как мы еще юзаем кучу «хайповых» технологий и с десяток дополнительных АПИ сервисов, то не знание всего проекта целиком для кого-либо на проекте подобно смерти.

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

                                А по факту самого процесса программирования, то мы тратим процентов 70 нашего времени именно на дискуссии, обсуждение бизнес логики, архитектуру и планирование. И только 30% на сам кодинг. В итоге мы успеваем все, так как ничего не приходиться по десять раз переделывать.
                                  +1
                                  Немного поясню смысл первого комментария (хотя, наверное, надо было это сразу сделать). По большому счету я примеры писал не для того, что бы получить на них ответ, а что бы стимулировать более конкретно сформулировать вот такие субъективные факторы. Скорее всего для вас лично это будет даже более полезно, чем для остальных. Хотя бы для того, что бы более осознанно принимать решения.
                                  Это в общем-то не сложно, та же самая аналитическая работа. Как говориться тыжпрограммист :)

                                  Любая фича сложная, которая не может быть самостоятельно закрыта одним разработчиком в относительно короткие сроки.


                                  А если фича может быть закрыта одним программистом, но не в короткие сроки?
                                  А если не одним, но в короткие?
                                  А короткие это сколько?
                                  А почему именно столько?

                                  Ну и так далее до измеримых величин.

                                  Перформанс увеличился раз в 10!


                                  Ну дык это еще в мифическом человекомесяце было отмечено, что увеличение команды скорость разработки не увеличивает :)

                                  А с 70% чет мне на вскидку кажется перебор. Но может это ваша специфика, не мне судить. Но почти наверняка при увеличении команды эффективность оооочень сильно просядет.
                                    0
                                    А с 70% чет мне на вскидку кажется перебор. Но может это ваша специфика, не мне судить. Но почти наверняка при увеличении команды эффективность оооочень сильно просядет.

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

                                0
                                Не туда
                                  0

                                  Можно только порадоваться, что у вас все получилось. Такие истории успеха часто слышу от работающих с иностранными заказчиками — у них другая культура и понимание, что подход "надо все переделать и сделать это надо было ещё вчера" не работает.

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

                                  Самое читаемое