Пользователь
0,1
рейтинг
8 ноября 2012 в 12:39

Управление → Мы сделаем этот велосипед за месяц

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

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

Велосипед


image
Итак, Вася долго трудился рядовым программистом, ведущим программистом и наконец стал Руководителем. У него есть команда отчаянных головорезов разработчиков в количестве двух единиц. Безусловно талантливых и знающих свое дело специалистов.

Вася получает первый заказ — надо сделать … велосипед.

К сожалению готовые велосипеды либо слишком дороги либо не подходят заказчику по ряду причин. Отлично, думает Вася, уж велосипеды-то мы делать любим и умеем, и радостно берется за разработку. Вася хоть и начинающий, но уже руководитель, и понимает что надо делать велосипед попроще, т.к. помнит про сроки, договоры, бюджеты и все остальное что является фундаментом принятия решений в коммерческой организации. Сделав задумчивое лицо, помолчав минуту, он отвечает заказчику, что на велик уйдет не меньше месяца, т.к. “задача сложная и нестандартная”. Думая про себя, что работы там на две недели, но разумно умножая на два. Вася все-таки был острожным парнем.

Он собирает команду и объявляет задачу: мы делаем велосипед. Заводит парней своим энтузиазмом, выслушивает гениальные идеи от каждого, сам воодушевляется общим настроем и принимает простое и логичное решение: сам Вася, как наиболее опытный, делает раму, Серёга, как лучший знаток передовых технологий, делает колеса, а Петя, как самый молодой, занимается прочим навесным оборудованием. Выпили кофе, порисовали на белой доске маркерами велосипеды в анфас, профиль и в разрезах и сели кодить.
Забегая немного вперед, мы увидим через месяц, что проект на грани провала, команда деморализована, а велосипед хоть уже и ездит, но недалеко и часто падает. Иначе и быть не могло. Что же случилось?
Краткая хронология
День 0
Старт. Воодушевление и креатив так и прут.
День 3
Серёга: Вася, колеса почти готовы, остались мелкие доработки. Когда будет рама чтобы примерить?
Вася: меня тут совещали с заказчиком, сейчас разгребусь и доделаю. А ты пока, чтобы дурака не валять, резину выбери, что-ли. Займись, короче, чем-нибудь полезным.

День 6
Петя: Вася, я сделал звоночек и зеркало заднего вида, смотри какие клевые! Но мне нужен руль чтобы примерить.
Вася: Руль? Черт. про руль мы не подумали. Ну да это же просто палка с резинками, ща запилим. Потом сделаем поприличнее.
А ты погоди пока, займись … исследованием подшипников! И давай цепь делай с педалями, они приоритетнее.

День 10
Вася: Серёга, вот тебе рама, Петя вот тебе руль. Фух.
День 13
Серёга: Вась, а че рама складная? А почему крепления не с той стороны? Переднее колесо влезло, а заднее цепляет.
Петя: Вась, я конечно звонок прицепил, но пришлось руль обпилить напильником, и теперь зеркальце болтается.
Вася: парни, ну вы со своей стороны подпилите чтоб к раме подходило, а я её немного доделаю, чтоб все собиралось.
(Тут первый раз за этот проект Вася засиделся до полуночи)

День 20
Демонстрация демо-велосипеда. Он падает, едет только назад, и пока у него нет седла, а переднее колесо больше заднего. Вася убедительно уверяет заказчика что возникли проблемы, но скоро все уладится.
День 30
После полной переделки рамы и переднего колеса велосипед выглядит получше. Также в авральном режиме удалось прикрутить старое седло. Но велик все равно катастрофически неустойчив, навесное оборудование пришлось сократить до цепи и педалей, а о красивой упаковке (бывшей последним пунктом спецификации) еще даже никто и не думал. Васю беспощадно совещают заказчики, директор и прочие уполномоченные лица. Команда деморализована.


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

Что же делать?


1. Спроектировать велосипед.
2. Спланировать работы и ресурсы.
3. Назвать заказчику дату.
4. Сделать велосипед.
5. ??????
6. PROFIT!!!!11


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

Планирование работ


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

Проведем простейшую декомпозицию нашей задачи:

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


Но чем будут заниматься Серёга и Петя пока Вася будет делать раму? Отдых это конечно хорошо, но не в данном случае. А почему бы не нарисовать сначала раму и договориться о размерах раз и навсегда? Имея нужные размеры Серега и Петя смогут занятся своими задачами. Кстати у нас есть задача по упаковке. Она не сильно завязана на все остальное, и её можно запускать сразу, как будут известны размеры. Итак, у нас все упирается в размеры. Выделим задачу по проектированию размеров рамы и посмотрим что же получится:


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

Ресурсы и сроки


Попробуем наложить получившийся план разработки на имеющиеся ресурсы:

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

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

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

PS: статья, включая диаграммы, сделана полностью в Google Docs, ради эксперимента. Удобная штука, как оказалось!
@ncix
карма
19,2
рейтинг 0,1
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (89)

  • +1
    Спасибо!
  • +8
    Просто, красиво, кратко, понятно — почти идеальный пример.
  • +4
    День 6 — Жизненно.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Полтора, как и три, как и прочее число — это очень средняя температура по больнице. По своему опыту разработчика, могу сказать, что я всегда оцениваю сроки сверху. Типа 30 минут — 4 часа. И чаще всего в них заведомо укладываюсь. В то же самое время, если я упустил какие-то архитектурные детали, то срок этот может на порядок возрасти даже от моих пессимистических оценок.
      • +1
        А ещё, время = деньги. Т.е. Если мы умножаем оценку времени на порядок, по сути на порядок мы умножаем и стоимость проекта для заказчика. В этом случае он может выбрать другую контору, которая прикидывает затраты более точно.
        • +2
          … которая прикидывает затраты более оптимистично. Потом 70% что заплатит больше, чем выставляли ценник мы. Но а) откуда заказчик сразу узнает, что мы лучше укладываемся в сроки и бюджеты и не косячим? б) 70% != 100%, заказчик халяву любит, есть задняя мысль, что можно будет «нагнуть» подрядчика на бесплатную доп.работу из-за туманности ТЗ и прочих подобных факторов в) потом — не сейчас, психологически (и организационно) проще заплатить больше, но за несколько раз и «неожиданно», заказчику остаётся поле для манёвра г) может быть, что всплывёт, что заказчику сойдёт продукт и половинного качества, или что он ему вообще нафиг не нужен.

          Так что реально «мы» предлагаем «водопад», а «другая контора» — метод более коротких итераций…
          • 0
            Не искажайте мои слова. Вы ведь не считаете себя супер-специалистом во всех вопросах. так что попробуйте предположить, что существует компания, которая лучше Вас разберается в некой разработке, и может выставить сроки более точно, чем Ваше «послушай программиста и умнож на число с потолка».

            Кстати, хороший тест команды. Спросить как они оценивают сроки. Если слышите что-то типа «ну мы спрашиваем наших программистов, они дают оценку сроков, плюс мы закладываем время на случай непредвиденных ситуаций» — бегите от такой команды куда подальше.

            Ну а метод коротких итераций в любом случае лучше водопада, особенно когда заказчик чётко не знает чего хочет.
            • 0
              Спросить как они оценивают сроки.
              Т.е. 70%, что попросить разгласить коммерческую тайну, если это не ваша же контора… такое не «спрашивают», а шпионят.

              Не искажайте мои слова.
              Более оптимистические оценки могут оказаться менее точными ;-) но при этом более привлекательными для заказчика ;-)

              существует компания, которая лучше Вас разбирается в некой разработке, и может выставить сроки более точно, чем Ваше «послушай программиста и умножь на число с потолка».
              Сомневаюсь. Иначе подрабатывали бы консалтингом в деле оценки и экспертизы проектов, а не разрабатывали бы сами;-) Хотя всё бывает. И для пиара покатит))
              • 0
                Т.е. 70%, что попросить разгласить коммерческую тайну, если это не ваша же контора… такое не «спрашивают», а шпионят.

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

                Вы уверены, что более низкие оценки, чем ваши — будут провальными для команды. Это не всегда так. Особенно если Вы выставляете сроки от потолка. Скорее это похоже на оправдание себя — «Мы выставили сроки и цену которая точно прикрывает нашу задницу (хотя точно оценить проект мы не можем), все остальные идиоты»

                Сомневаюсь. Иначе подрабатывали бы консалтингом в деле оценки и экспертизы проектов, а не разрабатывали бы сами;-) Хотя всё бывает. И для пиара покатит))

                У Вас высокая самооценка. А насчёт консалтинга и разработки — я не знаю ни одной консалтинговой IT фирмы, с доходами, сравнимыми с доходами MS, Google или Apple. Что наталкивает на мысль, что разрабатывать всё же более выгодно.
          • 0
            Раплывчатое, мутное ТЗ — косяк РП.
            Если ТЗ утверждено программистами и заказчиком, правки невозможны.
            В формировке четкого ТЗ и заключается одна из основных задач РП.
      • 0
        Но бывает, что программист оценил сверху, РП оценил сверху, в итоге сумма=сроки утраиваются, а то и больше. А это печально сказывается на лояльности заказчика.
        • 0
          Кстати, утроение названного исполнителем срока — не такая уж редкость. Это может спугнуть заказчика, если заказ ещё не получен, особенно если оптата почасовая. А так — финальное впечатление важнее вдохновления обещаниями. Закзачик строит свои планы относительно названных сроков, поэтому начальное разочарование названными сроками с лихвой покрывается эффектом от своевременного (особенно досрочного) выполнения, в противовес запозданию и невыполнению обещаний. И заказчик уходит довольным.
          • +4
            Что-то я никогда не слышал о досрочном выполнении IT-проектов. В вашей практике такое было?
            • 0
              Было. Изначально доработка оценивалась в 4 месяца с 3 этапами + тестирование по каждому. Заказчика это устроило. Но через 2 месяца мы уже перешли к выполнению 3го этапа без особых проблем. Перед озвучиванием новости об опережении сроков мы наступили на небольшие грабли, но в итоге доработка была проведена на 1,5 месяца раньше сроков, чему заказчик оказался несказанно рад, проигнорировав последующие задержки по другим проектам.
            • 0
              Разумеется. Ситуацию спасал как раз «буфер времени».
            • 0
              Было. И как раз это было, когда проект делал 1 (я) или 2 человека. А поэтому не было этих схем и управления процессом. Некем было управлять, а значит на каждом шаге определялось наиболее оптимальное направление. Но сроки указывали с буфером
          • 0
            А почему здесь никто не вспоминает о конкуренции — о том, что назвав такую сумму — с большой вероятностью договор не будет заключен?
            • 0
              Не всегда конкуренция — это только стоимость продукта. Нужно учитывать специфику работы компании. Вдруг с этим заказчиком уже сложились успешные отношения, вдруг уже есть рабочие проекты? А если обращение по рекомендации? Или в рамках гораздо более крупного проекта, то есть выгодно заключать договор только с компанией N?
            • 0
              Конкурентная борьба ведётся не только ценой. Если заказчик давно работает с исполнителем или его привело «сарафанное радио», цена уже не является решающим фактором для заключения договора.
              • 0
                Именно поэтому РП должен думать не только о сроках и компании но и уметь мыслить категориями Бизнеса.
                • 0
                  … а ещё уметь сделать продукт в одну харю в те же самые сроки;-)

                  Должен быть кто-то, кто умеет мыслить категориями бизнеса, но почему это должен быть именно PM?
                  • +1
                    Потому что хороший РП должен хотеть вырасти в техдиректора, например :)
                    • 0
                      Или потому что хороший РП учитывает не только свой проект, но и развитие компании о общем.
                  • 0
                    эээ, тоесть есть программисты/тестеры/дизайнеры, есть PM, есть «тот-кто-мыслит-категориями-бизнесса». И есть заказчик, в конце-концов. Знаете, по моему они никогда не договорятся. Слишком много народа :-)
                    • 0
                      Для команды РП — представитель заказчика и действует в интересах заказчика, для заказчика — представитель компании (команды) и действует в интересах компании (команды).
                      • +1
                        Ну стоит заметить, что разделение интересов на «Интересы команды» и «Интересы заказчика» — уже беда. Ведь цель у них одна — создать качественный продукт. А значит и интересы должны быть общими. Таким образом, РП (о боже, минут 10 не мог понять, что это сокращение значит, привык к забугорному PM) представляет интересы проекта.

                        Но, очевидно кроме собственно проекта, должны быть финансовые интересы фирмы и заказчика. И эти вопросы должны быть изолированны от команды. Хотя в небольших проектах, Руководитель проекта часто совмещает должности собственно PM и переговорщика с заказчиком. Но как известно, проще найти двух людей, один из которых будет хорошим PM а второй — хорошим переговорщиком, чем искать человека-оркестр.
    • +2
      Сроки, названные программистом, нужно делить на ноль.
      • 0
        То есть Вы предлагаете самостоятельно оценивать сроки, без участия программиста?
        • 0
          Сроки названные программистом — ничего не значат. У него настроение сегодня плохое (Сроки большие). А вот завтра будет хорошим, и сроки резко ужмутся. А вот оценка сложности — уже важная вещь. На основе которой Вы можете прогнозировать время выполнения задачи.

          Простой пример — есть тех. характеристики машины, сколько она тратит в городском/загородном режиме. Есть показания бортового компьютера. Есть растояние в километрах. Но только Вы, оценив маршрут до цели, свой стиль вождения и загрузку дорог можете прикинуть, сколько бензина Вам понадобится.
  • +1
    Здорово. Только пока вы проектируете (да даже велосипед) и тянете с указанием сроков, заказчик уже уйдет к Саше из другой конторы, который съев собаку на строительстве велосипедов, экспертно оценит сроки и прикинет, сколко это будет стоить с точностью 33%. Чего для болшинства заказчиков будет вполне достаточно.
    • +3
      Возможно. Но думаю день на предварительное проектирование и планирование вам всегда дадут. Какое-то представление о сроках уже можно будет получить.
      • +2
        Вот и получается, что ты сидишь, проектируешь, планируешь… А потом оказывается, что заказчик рассчитывал на сумму в 4 раза меньше, чем ты посчитал, исходя из времени, которую надо затратить на проект.

        И выходит, что день проработал зря, без всякой пользы, ничего не заработав.
        • +3
          Что ж вы предлагаете любой ценой заманивать заказчика, неважно справитесь ли с проектом за предложенные деньги?
          • 0
            Не столь категорично. Если кусок не по зубам, зачем пытаться «понадкусывать»?
            А с другой стороны, кто не рискует…
          • 0
            Есть такая тактика. А потом раскручивать на доп. бабло. «Метод коротких итераций» (vs «водопад») в применении к более высокому уровню;-)
            • 0
              При использовании коротких итераций можно составлять отдельное ТЗ на каждую и оплачивать по итерациям. Изначально спланировав проект целиком.
          • 0
            Я ничего не предлагал. Хотел узнать мнение более опытных коллег.

            Как один из вариантов, который мне предлагали — это составление ТЗ за отдельную плату. Но есть смутные доводы, что кто-то вообще решиться платить за ТЗ не увидив самого ТЗ )).

            Для себя пока избрал тактику называть заказчику минимальную цену, от которой мы будем работать для него. Так сразу отсеиваются те, кто хочет интернет-магазин за 20 т.р. В итоге не трачу на нищебр… несостоятельных людей свое время.

            Но, хочется верить, что есть способы мудрее.
        • 0
          Вот именно для этого нужны предварительные оценки, «на глаз».
          Без всякой пользы невозможно. Вы оценили, подумали, представили, создали черновик плана, еще что-нибудь. А заказчик ушел. Зато в следующий раз столкнувшись с подобным проектом Вы будете меньше и быстрее думать, по-другому будете говорить с заказчиком и он не уйдет.
        • +1
          Совсем без издержек не получится получать заказы.
    • +2
      Что всё таки лучше, чем потом пытаться влезть в сроки, названные от балды. Если заказчик нервничает от того, что Вы сию минуту не можете назвать сроки — что будет, когда вы их начнёте срывать?
      • +1
        Я, как заказчик, заведомо знаю, что сроки будут сорваны. И вношу на это коррективы. В разумных пределах. Такова реальность, увы. Самая смешная тенденция, которую периодически замечаешь — заказчик ставит в качестве условия заведомо невыполнимые сроки, что понятно обеим сторонам. Делается, это, судя по всему, из логики: «Если мы договоримся на месяц, то за два вы точно управитесь. А вот если изначально планировать на два, то не меньше трех реально выйдет...»
        • 0
          А вы как заказчик будете бурно реагировать на срыв сроков, даже если изначально это запланировали?
          • 0
            It depends. В разумных пределах — нет. Если очередной месячный отчет/релиз приходит на пару дней позже — можно считать это техническими проблемами. Если на неделю — повод немного помотать душу. Если месяц — то что-то кардинально не то либо в оценке поставленной задачи либо в производительности труда. Последняя ситуация указывает на проблему с компетентностью как подрядчика/исполнителя, так и, возможно, на мою. Цифры условные и приведены для примера.
        • +1
          Тоесть фактически вы выполняете задачу руководителя.

          Конечно, смышлённый заказчик всегда закладывает «подушку» в сроки, ведь всегда могут быть коррективы, даже если проект закончен во время. Но далеко не всегда можно умножить сроки в несколько раз. Тем более, факт значительного срыва сроков обычно указывает на то, что команда не профессиональна, а значит, даже если Вы будете ждать в 2-3 раза дольше — результат всё равно будет печален(Вам ведь его ещё потом развивать/поддерживать). И лучше вот прям сейчас искать других исполнителей.
        • +1
          Поддерживаю!
          Лучше назвать предварительные сроки с оговоркой, что более конкретные будут даны после детального анализа проекта. Это подготовит заказчика.
    • 0
      Съесть собаку на уникальных дизайнах невозможно. Я, конечно, не говорю о конторах, которые делают говносайты под копирку и говноприложения типа «веселой фермы».
    • +1
      съев собаку на строительстве велосипедов
      Помедитируйте над этой фразой. Хорошо помедитируйте. Ситуация, которая ею описывается, в применении к софтостроению кажется мне малореальной и дурацкой (если не брать область «сайт на LAMP за полдня и 200 баксов»). «Съедание собаки» должно довольно быстро обернутся изготовлением «фабрики велосипедов», резко удешевляющей изготовление велосипеда.
  • 0
    Это гениально!
  • +5
    Спасибо! Полезно для начинающих РП.
    Добавлю, что умножение оценки программиста часто зависит от самого программиста. Оптимисты называют N часов, я прибавляю 70%, пессимисты — M часов, я прибавляю 20%. То есть в зависимости от опыта работы с конкретным человеком или с конкретной командой я всегда прибавляю 20+ % к оценке сроков, тем самым заведомо перекрываю время на напильник.
    Многократно при озвучивании даты=оценке заказчику, даже внутреннему, знающему лично исполнителей, приходилось потом отдуваться за задержки. Особенно это касается небольших проектов=доработок, уже завязанных на работающие проекты компании.
    Например, если есть рабочая система, а к ней нужно добавить рюшечку, нужно учитывать не только оценку программиста+%запаса, но и отвлечение программиста на чай-кофе-перекуры-другую текучку. Потому что рабочую силу могут выдернуть на что-то более важное для Бизнеса в любой момент. Это проблема любой компании, у которой много мелких, тесно связанных между собой проектов и нет четкого разделения на команды разработчиков в привязке к проектам.
    • +1
      Например, если есть рабочая система, а к ней нужно добавить рюшечку, нужно учитывать не только оценку программиста+%запаса, но и отвлечение программиста на чай-кофе-перекуры-другую текучку. Потому что рабочую силу могут выдернуть на что-то более важное для Бизнеса в любой момент. Это проблема любой компании, у которой много мелких, тесно связанных между собой проектов и нет четкого разделения на команды разработчиков в привязке к проектам.

      По-идее все это решается глобальным планом по всем ресурсам. Т.е. вставляя новую задачу с приоритетом, мы двигаем какие-то другие задачи, и эта информация четко доносится до того кто эту задачу пытается пропихнуть. Будь то хоть сам генеральный. Таким образом ответственность за срыв сроков по другим проектам перекладывается с РП на того кто имел полномочия раздвинуть план. И ни в коем случае никогда и никаких неучетных задач, даже «на 5 минут».
      • 0
        Согласна, это прекрасно работает, когда в компании налажен процесс. А когда бардак? Или компания расширилась за полгода с 10 до 100+ человек?
        • +1
          Бардак надо систематизировать и искоренять. То что работало для 10 человек не будет работать для 100. Процесс этот очень тяжелый, и сопряжен с большими рисками. Многие не выдерживают и уходят. Неизбежны регламенты, планы, согласования и прочая бюрократия, иначе все развалится.
          • +2
            В условиях бардака, даже когда топ-менеджмент активно и успешно его искореняет, невозможно на 100% полагаться на ресурсы и давать сроки по формулам.
            Не так давно сменив работу, я ушла из перманентного застойного бардака в бардак позитивный, живой и очень этому рада. Я вижу конец этому бардаку. Да, работать мешает, но скоро кончится.
            При этом я согласна быть готовой всегда готова к тому, что моего ключевого разработчика уведут на «очень надо, прямо сейчас», а я об этом узнаю поздно.
            Как лекарство можно применить ходьбу ногами и многократные уточнения состоянием по ходу разработки/тестирования. Но далеко не все это любят, особенно тимлиды.
            • +1
              >> невозможно на 100% полагаться на ресурсы и давать сроки по формулам
              Можно просто заложить некоторую эластичность в оценки, пропорциональную размеру бардака в компании.
              С другой стороны, «позитивный бардак», как вы сказали, неплохо работает в небольших компаниях, имеющих хорошую рыночную нишу и молодой коллектив.
              • +1
                Именно поэтому ритуальные танцы над оценкой сроков с закладкой на бардак/ресурсы/бизнес/ это искусство :)
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Если не ошибаюсь, вы занимаетесь играми. То есть тиражируемым софтом. В тиражируемом софте тоже есть заказчик (прОдукт менеджер, или тот кто ставит задачи разработке). Хоть и отношения несколько иные, но есть много общего с классической схемой заказчик-исполнитель.
      • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    Закон Хофштадтера: «Любое дело всегда длится дольше, чем ожидается, даже если при планировании учесть закон Хофштадтера.»
    ru.wikipedia.org/wiki/Хофштадтер,_Дуглас
    • +1
      Значит, если при планировании не учесть закон Хофштадтера, то дело продлится в среднем меньше.
  • +1
    Я не понял проблемы в примере. Велосипед ездит в конце месяца? Ездит. Презентация была? Отлично.

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

    Бывает, что и за год велосипед не поедет и вообще не поедет никогда. Вот это провал. А в данном случае всё отлично. На моей памяти всегда проекты превышали время, кроме случаев, когда один-два человека разрабатывали и не нужна была сложная координация.
    • 0
      Завал сроков без четкой аргументации даже на неделю без предварительного предупреждения — провал РП.
      • +3
        не будьте идеалисткой. Пацан сказал — пацан сделал — это для бандитов обоснование. А у программистов часто есть объективные причины, которые возникают во время разработки и их нельзя было учесть во время планирования.

        Проблема в планировании ИТ процессов имеет глубокую основу.

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

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

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

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

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

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

        Далее, чтобы надеяться на программистов — набирайте опытных программистов. Тогда их ругать бессмысленно за проваленные сроки. Хороший, опытный программист, на работе работает и работает хорошо. Если не получилось, значит не могло получиться. У него нет свободного ресурса. Он не играл на рабочем времени в игры. Нерабочее время не учитываем.
        • +3
          Уже который раз сталкиваешься — как бы ни писали ТЗ, все равно оно будет изменено, все равно чего-то не учтешь.
          Как бы ни заинтересован был заказчик в результате — с его стороны все равно будут задержки по просмотру/приемке/утверждению/согласованию.

          Я для себя уже принял как факт:
          1. Оценку программиста надо умножить на 2 и добавить еще чуть-чуть. За 6 лет работы РП — сходится в 95% случаев
          2. В ТЗ будут внесены изменения, причем такие, что обосновать дополнительную стоимость будет ОЧЕНЬ сложно, а время на решение задачи увеличится и придется что-то переделывать.
          3. Заказчик быстро не реагирует. И надо закладывать в буфер времени (получения оплаты) — некоторую величину, которая тем больше, чем крупнее заказчик.
          4. Не добавлять программистов к проекту, когда он уже заканчивается (ну или стремится к этому) — золотое правило еще от Брукса.
          5. Для больших проектов — не использовать новые, непроверенные временем инструменты или технологии.
          • +3
            Ну и еще — наличие или отсутствие ТЗ — довольно мало влияет на время разработки.
            Есть ТЗ — все равно придется переделывать какую-нибудь концептуальную хрень, которая сильно затянет срок.
            Нет ТЗ — все равно придется переделывать какую-нибудь концептуальную хрень, которая сильно затянет срок.

            Единственное, что иметь ТЗ удобно программисту — как руководство к действию, спокойно почитать и не отвлекать РП
            Ну и если закачик хочет фантастическую штуку — можно обосновать что этого в ТЗ не было.
            А и еще — бывает что возникает большой пласт работы в конце проекта и необходимо сделать дополнительную фичу, которая в ТЗ не прописана, но всем понятно, что если ее не сделать — проект никому не нужен будет.
    • +1
      Так в типовой ситуации, как правило, с проектом все-таки справляются. В примере описана проблема отсутствия плана разработки. Если бы он был — через месяц был бы красивый велик в упаковке и без головняков для Васи и его команды.

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

      PS: Вообще напрашивается целый цикл статей про Васю и его команду. Судя по популярности этой статьи, серию может ожидать оглушительный успех :)
      • 0
        Я не считаю, что планирование нужно. Какое-то общение вначале. Лучше, быстро, очень быстро, за пару дней склепать, склеить прототип из бумаги.
        Очень хорошо, это попытаться описать и условиться на счет интерфейсов. Т.е. размеры. Интерфейсы, которые нужны только для разделения работ отдельных программистов.

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

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

        Кстати, замечали когда-нибудь, что если всё распланировать, один хрен почти вся работа делается в последних два дня перед дедлайном. Поэтому режим аврала намного более эффективен. Если научиться им управлять, эффективность разработки возрастет в разы, а то и в десятки раз.
        • 0
          Многое еще зависит от психотипа ключевых людей в команде. Кому-то комфортно в аврале, кому-то — при четком распараллеливании. Я не сталкивалась с исполнителями, которым нравится аврал. Руководители — да, любят нагнетать.
        • +1
          Знаете, эта статья в многом автобиографична. Я как и Вася долгое время забивал на планирование и закономерно получал ж. Но жить годами в постоянном аврале и факапе сроков стало невыносимо. Поэтому я сел и разобрался где же задница. И результатом стала эта методика. У меня она показала хороший эффект. Но это конечно не серебряная пуля, небольшое подспорье в работе РП.
          • +1
            Конечно, статья хорошая и смысл в ней есть. Только, имхо, не надо впадать в другую крайность — в водопад.

            Распараллелить работу — вполне нужно. Но и помнить, что траектория снаряда всё время меняется и надо по возможности чаще общаться и корректировать планы.

            А работа в режиме аврала, если привыкнуть, совсем не изматывает. Это просто работа, почти под сто эффективности, немного меньше. От звонка до звонка. Не по ночам и не по выходным. Умение программистов быстро комуницировать между собой, принимать решения и не полагаться на какой-то план. План для программиста — это всего лишь способ урвать свободное время. Завершил на пару часов раньше задачу, можно ничего не делать. А это негативно влияет на производительность. Любое отвлечение от работы, потом тяжело снова начинать. И так работать — еще больше изматывает. Наиболее тяжелая работа для программиста — это когда нет работы.

            Вот я сейчас каменты пишу, потому что по планам задачу выполнил, которую должен сдать в понедельник )))
            Правда, сейчас придумаю себе задачу и перестану писать ))
            • +1
              >> Умение программистов быстро комуницировать между собой, принимать решения и не полагаться на какой-то план

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

              А то что план может меняться на лету — совершенно справедливо. Но надо же с чего-то начинать.
        • 0
          Смотря что звать «планом» — сетчатый график или детальную разблюдовку по часам.
  • 0
    Это стоило бы почитать конструкторам суперджета
    • 0
      Да нормально его сконструировали, там импортный высотомер глюканул…
      • 0
        Речь про Индонезию, или про что-то другое?
        • 0
          Про неё, да.
  • +2
    Спасибо от начинающего руководителя! =)
  • +1
    Хорошо показано, что с ростом команды для обеспечения распараллеливания возникает необходимость в доп. работе — в частности, по предварительной разработке интерфейсов.
  • 0
    Интерфейс всегда продумывается предварительно! Иначе будет ну ни разу не юзер френдли :)
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Проект интерфейса должен существовать да начала разработки.
        • 0
          Вообще-то в статье я говорил об API, не о GUI. На счет GUI не все так однозначно, в какой момент его начинать делать.
          • 0
            Согласна, неоднозначно.
            Но все же при проектировании архитектуры будущего продукта стоит уделить время основным элементам пользовательского интерфейса.
            Чтобы не получился велосипед, который быстро едет, управляем, но элементы управления неудобны или неочевидны.
            Согласитесь, переключать скорости руками под сиденьем неудобно :)
            Если сразу заложить элементы управления=использования с учетом сценариев использования, то продукт будет удобен и неперегружен лишними настройками.
            Очень печально использовать программные продукты и испытывать недовольство от кучи излишних параметров и необходимости делать 8 кликов для 1 простого и постоянно повторяемого действия.
            Это я и понимаю под проектированием интерфейса одновременно с элементами системы.
            А когда продукт разрастается без плана, почти всегда на выходе получаются перегруженные интерфейсы и недовольные пользователи.
            А что касается API, то это тоже интерфейс. но для разработчика. И он тоже должен быть продуманным и удобным, а так же проектироваться на стадии общего проектирования. Добавлять в наспех придуманный API новые функции нехорошо.
            • 0
              Все это прекрасно и верно, но только в случае фиксированных и неизменных требований заказчика. А такого в моей практике не случалось, к сожалению :)
              • 0
                Но ведь можно зафиксировать требования хотя бы на первую итерацию/билд?
                А потом уже править методом комплексного добавления/удаления опций :)
                Всегда можно найти компромисс, если очень захотеть.
                В моей практике. к сожалению, было мало продуктов, для которых требования бы не менялись вообще. Но все же такие случаи были и это великолепно сказалось на конечном продукте.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Если мы говорим об интерфейсах программных продуктов (не важно, веб., десктоп или клиент-сервер), то нужно думать не только о функционале и архитектуре, но и о сценариях использования.
            Программист, разрабатывающий на основе API продукта, в определенном роде тоже пользователь и его потребности нужно учитывать.
            При этом кнопочки и их местоположение не входят в это проектирование, они будут сделаны потом.
            Недаром есть специально обученные люди, привлекаемые для проработки пользовательских сценариев еще на стадии проектирования.
            А еще фокус-группы из потенциальных пользователей, благодаря которым можно учесть и исправить замечания и неудобности…
            Проблема в том, что понимание необходимости этих действий есть далеко не у всех руководителей и далеко не на всех проектах.

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