Дайте мне работать-2

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

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

    Для начала, давайте рассмотрим типичные роли в типичной IT-компании. Обычно, упрощенно, есть 3 уровня. Если есть 2, то это либо очень маленькая компания либо очень глупая. Итак:

    1.Программисты — реальные исполнители, рабочие лошадки, те кто реально делает работу, пишет код, поддерживает и обслуживает проект
    2.Менеджмент — это тех. директор, ПМ, продюсер, маркетинг и т.д., то есть люди кто осуществляет непосредственное руководство проектом, постановку задач, планирование и др.
    3.Заказчик — тот кто дает деньги, обеспечивает бюджет, и главное это тот, кто хочет получить прибыль. Это главный чел, именно тот из-за кого вообще весь этот сыр-бор.

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

    Казалось бы, IT-таджики — самый лучший вариант. Но давайте задумаемся ради чего работают IT-таджики? Они работают ради своей зарплаты. Они готовы делать все, что скажут, лишь бы платили деньги. Если менеджмент горит «надо», «Джамшут» отвечает «есть»! Важно ли этому Джамшуту получит ли заказчик прибыль или нет? Да, может какой-то извилиной он и понимает, что прибыль заказчика позволяет ему платить зарплату, и потому, прибыль заказчика конечно важна. С другой стороны, ну обанкротится он, ничего страшного, можно найти новую работу. Да и поднимет ли заказчик зарплату, если его прибыль вырастет? Заметит ли вообще твою заслугу? Стоит ли овчинка выделки? Даже если Джамшут сумеет додумать эту мысль до конца, ответом скорее всего будет «Нет». Поэтому этот чувак никогда не будет делать что-то, что выходит за рамки поставленных менеджментом задач, даже если он видит что это, прямо или косвенно принесет прибыль Заказчику.

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

    Понятно, что для Заказчика конечная цель — получение прибыли, но между всем прочим Заказчик хочет, что бы:
    1.Задачи выполнялись быстро
    2.Работа выполнялась качественно
    3.Любые новые задачи быстро попадали в план, и выполнялись в кратчайшие сроки

    Но соответствует ли это целям менеджмента, вышедшего из IT-таджиков? Нет!

    1.Менеджменту не надо выполнять задачи быстро, потому что чем дольше длится проект, тем больше раз удастся сходить в кассу. Новый проект может и не появится, либо за него будут платить не столько, и он может быть сложнее (придется работать), а начинать новый проект всегда сложнее чем продолжать старый. Менеджеру выгодно внушить заказчику, что проект не может идти быстрее, что программисты тупые, что планы слишком часто меняются и тд. Все что бы тормозить проект любыми средствами. Это не выдумка. Я работал в одной компании, и случалось когда мы реально всей командой сидели, и пытались растянуть трехмесячный план на полгода. То же самое было и в других компаниях, когда проект специально переделывался несколько раз, что бы растянуть время и получить как можно больше ежемесячных бонусов.
    2.Менеджменту не надо больше качества, по причинам описанным выше. Чем больше ошибок, тем больше длится проект. Наличие ошибок с одной стороны позволяет показать заказчику сложность проекта, с другой стороны, держать на короткой уздечке программистов, внушая им что у них руки-крюки, а заказчику, что во всем виноваты программисты. Ошибок не должно быть слишком много, но определенный уровень необходим. Но не только ошибки — проблема качества. Часть проблем качества продукта связанны со скоростью, с юзабилити, дизайном, гибкостью. Все это не нужно менеджменту. Это лишняя работа, за которую заплатят столько — же. Многие из улучшений будут просто не заметны заказчику. Если их ввести, он принесут ему дополнительную прибыль, но доказать, что эти прибыль была результатом работы менеджмента нельзя. Поэтому менеджменту достаточно держать планку качества на уровне «удовлетворительно». Выше нет смысла.
    3.О, это наверное самая сытная «кормушка» для менеджмента. Осознают они это или нет, но это так. Менеджер стремится внушить заказчику что внесение изменений это очень трудоемкий процесс. Что задачи должны ставится заранее, и планы это гранитные монолиты, не терпящие изменений. Менеджеры даже пишут толстые ТЗ, и носят их на подпись Заказчику. А если приходит таки новая задача, то это еще один повод растянуть проект. Если вы Заказчик, не верьте кислой роже менеджера, когда вы начинаете разговор о новой задаче, отсутвовавшей в плане. Он так маскирует свою радость, от того, что проект можно еще немного растянуть :)

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

    Что же делать? Выход в незаслуженно заклейменных IT-художниках. Вспомним разницу — таджики работают за оклад, художники — за идею, за результат. Лучшей наградой художнику, будут не деньги за его картину, а его собственное удовлетворение результатом, восхищение зрителей на выставках и критиков в профессиональных журналах, а так же память потомков. Если ему удастся продать халтуру, это не вызовет у него большого удовлетворения. То же самое с IT-художником. Ему важен результат, ему важно, что бы кто-то подошел и сказал «вау, ты выполнил такую сложную задачу, и ни одного бага!»
    Таковыми они остаются и на руководящих должностях. И именно такие нужны хорошему заказчику, потому что его цели и цели IT-художников схожи. По пунктам:

    1.Менеджмент, состоящий из IT-художников стремится выполнить любую задачу быстро, как только может. Во-первых, больше всего боятся они рутины, и задачу необходимо выполнить до того как она превратилась в рутину. Сам проект, если он вялотекущий, может надоесть, потому менеджмент стремится сделать проект динамичнее, что бы он развивался быстро, быстрее появлялись новые задачи. Тем самым проект никому никогда не надоест, и производительность труда не будет падать. Во-вторых IT-художник не боится новых проектов, и даже наоборот, рад завершению любого проекта, да еще и в рекордные строки. Ведь это повод для гордости, повод рассказать всем как быстро и качественно мы завершили такой сложный проект.
    2.Художники не любят рутины. А правка багов это рутина. Потому естественное стремление — багов не допускать. Став начальником, это чувство остается. Если IT-таджикам, без разницы над какой задачей работать, лишь бы денег платили, IT-художник будет любым способом избегать появление багов, и править их как можно быстрее. И менеджменту нет никакого удовольствия ломать все планы, задерживать проект. Откладывать новые задачи ради того, что можно было бы и не делать. Их приоритетом всегда остается скорость и динамика проекта. Баги это тормоза проекта. Поэтому работа будет нацелена на то, что бы создать такие условия, в которых количество ошибок будет минимальным. Например, изначально грамотно ставит задачи, пытаясь учесть возможные проблемы, или внедрить модульное тестирование.
    3.Как я и написал выше, динамика проекта это главное. Поэтому внесение изменений это не зло, это благо. Но для того, что бы постоянные пересмотры планов действительно не стали проблемой, необходимо правильным образом поставить работу, процесс внесения изменений в план, распределение и перераспределение задач. Для этого надо работать, и это еще один стимул для менеджмента состоящего из художников. Вместо того что бы внушать заказчику, что изменяемость приносит вред, они потратят усилия на то, что бы работа была поставлена так, что бы внесение изменений не вредило проекту. Это же еще одна интересная задача! Это же так увлекательно, и сколько удовольствия будет когда все получится!

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

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

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

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

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 251

      –11
      отлично написано. мне лично очень понравилось. держите плюс в карму. пишите еще плиз в таком же духе. разделяю ваше мнение
        +11
        Спорно это все, IMHO. Возможно, мне в этом плане «везло» (везение всякий может понимать как ему заблагорассудится), но мне чаще попадались именно «IT-художники» (в терминологии автора топика), или IT-перфекционисты (в моей собственной терминологии). И именно они благополучно запарывали весьма перспективные проекты, пытаясь внедрить нечто, «прямо или косвенно приносящеет прибыль Заказчику».
        Причем речь здесь не о неудачных попытках внедрения. Попытки, и, соответственно, внедрения, как раз, чаще всего оказывались успешными. А вот сроки напрочь срывались.
        Возможно, идеальным был бы некий вариант XP, когда за компом сидело бы 2 человека — перфекционист, трудяга (термин опять же мой — соответствие с терминологией поста каждый может отыскать самостоятельно) и менеджер. Трудяга остужал бы перфекциониста, перфекционист пинал трудягу, а менеджер, в случае, если пинание увенчалось бы успехом, уточнял бы у Заказчика — а надо оно ему, или нет.
        Впрочем, сдается, мое предложение тоже панацеей не является.
          –3
          если сроки срывались, это может говорить о неверном планировании. Есть такое дело, программисты любят переоценивать свои силы. С другой стороны сжатые сроки позволяют мне держать себя в тонусе, стремится к может быть изначально невозможному. Выходом из этого является измерение и подсчет реальной скорости каждого программиста, и корректировка его прогноза. Этим редко кто занимается, обычно просто умножая сроки надва.
            +4
            да нет — планирование вроде как на уровне. То есть со скидкой на переоценку. Вернее — в данном случае — со 100% наценкой. Менеджмент прихрамывал — то есть не замечал вовремя увлечения программистов улучшениями кода и архитектуры — а когда замечал, проект уже сильно отличался от изначального ТЗ. Отличался в лучшую сторону, но вот беда — Заказчик, даже если он все понимает и ему само по себе идея нравится, иногда бывает поставлен в условия, что ему просто надо ехать. То есть он готов ехать и на жигулях, и на мерседесе. Мы ему изначально собирались жигули предоставить, а тут такая бодяга — вместо жигуля — мерседес. Но не совсем собранный. ТО есть водительское место отличное, и левое переднее колесо, а уж какой у него домкрат…
            Можно было бы попинать на никчемность менеджера проекта (и мы, разумеется, пинали), но автор топика чуть шире мыслит. Ну я в след за ним пытаюсь.
            У меня есть ощущение (во многом сформированное собственным опытом — сам грешен внесением изменений по ходу разработки), перфекционист всегда будет пытаться сделать лучше, чем спроектировано, тем самым внося разброд и шатания в работу всей команды.
            P.S. Это ни в коем случае не означает, что перфекционисты не нужны. Просто надо уметь правильно их готовить. И одного менеджерского надзора может не хватить (не говоря уже о том, что если этот надзор окажется слишком плотным, велика вероятность перфекциониста потерять — он либо уйдет, либо махнет на все рукой и превратится в трудягу)
              –1
              В чем то согласен, но не совсем. Мы горим же что и менеджмент не таджики. То есть в их собственных интересах делать так что бы заказчик был доволен. Это главная мысль статьи. И почему менеджер сразу представляется как чувак с кнутом? Ведь есть и другие способы управления, чем тотальный контроль. Это даже скорее зависит не от контроля, а от созданной атмосферы в команде. Ну например, если менеджмент не терпит новых задач, и всяких улучшений, их постоянно отбрасывает, программист будет делать их тайно, не афишируя. Но если менеджмент открыт к рацпредложениям, мало того сам иногда корректирует процессы, вносит идеи, контролирует архитектуру, то программист всегда пойдет со своим предложением в начальству, ну что бы его хотя бы по головке погладили. И тут менеджмент может с легкостью контроллировать все творческие процессы, находя золотую середину.

              Надеюсь понятно расписал. Это я к тому что не надо все сваривать на программистов. Чаще всего любые проблемы проекта — недоработка менеджмента.
              0
              Пригляделся — а автор топика — это же вы. Сорри, за обращение в третьем лице. Глаз замылился. Я сейчас как раз пишу для нашего сайта текст про внешний контроль исполнения, причем примерно на ту же тему, что и ваш топик, посему, видимо, мысли где-то «за витали».
                0
                программисты боятся показаться медленными, особенно когда видят как соседа по офису увольняют за «не эффективность»…
                +3
                Не согласен. Бесталантливых людей (трудяг, исполнителей), работающих за еду, вообще не должно быть. Должны быть роботы, создать которых могут лишь талантливые творческие люди.
                И вообще, бизнес — дерьмо, если главная его цель деньги. Деньги, которые затем разменивают на спокойствие, надежность, комфорт и еще уйму бездыханного преходящего дыма, который так дурманит узколобых исполнителей. Бизнес только тогда пристойная форма жизни, когда деньги и все что за ними (надежность, комфорт и т. д.) разменивают на дело.
                Исполнители — это следствие недостатка культуры и самопознания, отсутствия чутья и воли к свободе. Исполнители — это чума доставшаяся нам от темного и безграмотного прошлого. Это хребет косных корпораций и оплот бессмысленных войн. Но грядет новое время, где власть не принадлежит купюре, где в креслах заседают не надменные скульптуры, где каждый сам себе голова и люди объединяют усилия ради прогресса всеобщего, а не личного (кстати, настоящий ум понимает, что по-настоящему хорошо может быть у тебя только тогда, когда хорошо у твоего соседа). Где идеал успеха замещен идеалом служения, как и завещал прекрасный муж Эйнштейн. Где технократия — форма правления. Где серая исполнительная мышь более не существует, потому что ей не дают есть, так как она всегда тормозит технологию, вместо того, чтобы ее двигать.
                Говорят нам нужны еще рабы, чтобы делать грязную работу. Но я готов сам рубить дрова, варить кашу, собирать картошку, чистить туалет, если того еще требует отсутствие технологий. Это вранье, что исполнительные рабы как бы полезны. Если бы еще вчера хотя бы десятую их часть разменять на прекрасные творческие головы, сегодня было бы уже то время, когда рабы вообще не нужны.
                Я бы хотел, чтобы все руководители никогда не брали на работу серых исполнителей. Тогда последние исчезнут как вид. А руководители только выиграют как личности. Ведь на самом деле, делать талантливых людей дисциплинированными — благое дело, а дисциплинированных людей талантливыми — пустая трата времени. Может быть это сложный подход, требующий нервотрепки, но зато он героичный и стоит того, что бы ради быть руководителем.
                  +1
                  Ура товарищи!!!

                  Простите — вырвалось…
                    0
                    (броневик прилагается)
                    :)
                  –6
                  Роман, я вас поздравляю — это первый ваш пост, с которым я практически полностью согласен. Благодарю вас за то, что а) вы сказали то, что должно было быть сказано; б) систематизировали и подытожили, не отвлекаясь на частности (что вело к холиворам).
                  На объективность/абсолютную истину не претендую.
                    –2
                    >это первый ваш пост, с которым я практически полностью согласен

                    Это не может не радовать. Значит картина точно удалась)))
                    –4
                    Присоединюсь к предыдущим комментаторам и поблагодарю за интересную статью!
                      +24
                      Возражаю, но постараюсь кратко, предметно :)

                      >> Итак, можно поделить IT специалистов на IT-таджиков и на IT-художников
                      Нельзя.

                      >> Оглянитесь вокруг, в России это повсюду!
                      Отличный аргумент, когда нет аргументов.

                      >>Художники не любят рутины. А правка багов это рутина. Потому естественное стремление — багов не допускать
                      Нет. Естественное стремление вольных художников — бросать проект, когда баги начинаются.

                      ИМХО: статья более пафосна и менее логична, чем первая. Извините, если чем обидел.
                        –6
                        Мой опыт показывает что поделить можно. Опыт немаленький. Опыт работы во многих компаниях, в больших и малых командах. Статья не из пальца высосана, она полностью отражает мой опыт, и основана на нем.
                          –2
                          Так я и не говорю, что из пальца ) С первой частью статьи я даже согласился.
                          Пусть мой комментарий останется ИМХОм =)
                            0
                            >Опыт работы во многих компаниях, в больших и малых командах

                            Недавно слышал как директор одной довольно крупной компании отклонил кандидатуру программиста, потому что у него в трудовой книжке не было ни одной работы продолжительностью больше года. По его мнению это говорит о том что или человек не уживается в коллективе или не усидчив, или что «свалит при первой же проблеме».
                              –2
                              У меня в трудовой есть работы продолжительностью год и более. Но в любом случае это может говрить о том что человек просто не нашел пока своей компании. Это может говрить об исключительно быстром прогрессе этого человека, и о том что компании в которых он работал не смогли его знания использовать.
                                0
                                Это может говорить о чём угодно, но если комания ищет стабильного сотрудника не на один год, то лучше для неё будет взять человека уже имющего опыт длительной работы.
                                Исключительно быстрый прогресс — звучит неправдоподобно. Даже в случаях сопровождения средних проектов, иногда может потребоваться около года, только на то, чтобы человек влился в проект. И что же получается, что после всех затрат на обучение, человек говорит: отлично, я всё понял, у меня быстрый прогресс, мне теперь здесь тесно, я пошёл развиваться дальше? =)
                                  +1
                                  думаю мести под одну гребенку тоже не стоит. но как сигнал да, можно рассматривать
                            –4
                            >Естественное стремление вольных художников — бросать проект, когда баги начинаются.

                            Если у проекта нормальный менеджмент, баги никогда не станут его проблемой.
                              +2
                              Покажите мне, пожалуйста, то место в моём комментарии, где я говорил про то, что баги станут проблемой проекта.
                                –1
                                >бросать проект, когда баги начинаются.

                                  +1
                                  И где там про проблему? :)

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

                                  Изложите, пожалуйста, каким образом вменяемый менеджмент, по-вашему, поможет расправиться с багами в такой ситуации?
                                    –3
                                    если багов немного, и они занимают небольшое количество времени то никто никуда не убежит. если убегают значит баги занимают много времени, значит они являются проблемой.

                                    >каким образом вменяемый менеджмент, по-вашему, поможет расправиться с багами в такой ситуации?

                                    Надо просто такой ситуации не допускать.
                                      +6
                                      Ну хз, хз. В моей текущей команде ведущий программист — такой вот художник. И когда его просят сделать мердж из бранча в транк (ну, перенести полезные изменения в побочной ветви) он говорит «это скучно и неинтересно заниматься этой рутиной, я не хочу это делать». Как быть тут?

                                      >> Надо просто такой ситуации не допускать.

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

                                      В любом случае, за статью спасибо.
                                        –2
                                        >когда его просят сделать мердж из бранча в транк

                                        не понял… это 15 секунд делов, как можно успеть соскучится? )))) Дайте ему, в конце концов звдвчу автоматизации процесса, что бы сократить время до 5 секунд. Задача интересная, времени займет не много, зато сэкономите его 10 сек. Шутко)))

                                          +2
                                          Шутко хорошая, потому как боюсь, что результатов мы не увидим =)
                                          Не, там в мердже не так просто, потому как выборочные коммиты переносятся. У меня ушло 2 дня только на то, чтобы понять, какие коммиты надо переносить, потому что проект очень большой, разбит на субпроекты :)

                                          Ну так о чем это я… Собстно, о том, что это пресловутое «неинтересно» просто как серпом по… пульсу проекта :) А вот «IT-таджик» такое не скажет — он медленно, но верно доделает работу.

                                          Видимо, тут прослеживается явная аналогия с темпераментом.
                                            –1
                                            ну вот значит у вас плохо поставлена работа с свн. Этим все объясняется в не проблемами IT-художников.
                                              +2
                                              Это не регулярная, а разовая работа — порядка 2к коммитов в 11 ветках. Обычно все действительно проще, укладывается в 10 минут.

                                              Но это должен же кто-то был сделать :) А художникам это — «не в жилу».

                                              P.S. У нас не svn, а TFS; в нем есть свои проблемы мерджа, что еще более доставляет. Менять его на svn — политика компании не позволяет. Я себе поставил гейт tfs2svn, и работаю через него, но остальным художникам «технические трудности неинтересны» :)
                                                0
                                                это должен делать тот кто работает в ветке. а не кто-то другой. я вообще никогда мержи не рассматривал в качестве нагрузки. это часть работы над задачей. я вообще никак в толк не возьму как это может вызывать проблемы. все проблемы с мержами были всегда виной менеджмента или разработчиков.
                                                  +1
                                                  Извините, что пристал с прикладной проблемой :) Просто жизненая ситуация — в транке лежит «четверка», в одну из веток ушел «4.6» — для одного из заказчиков. Порядка полутора месяцев (пара длинных спринтов) 3+ведущий «педалят» 4.6, а затем понимают, что в 4.X хотелось бы видеть многое оттуда.
                                                  Надо переносить. А кому?
                                                  Имхо должен ведущий программимст, а он — крутит носом, потому что счас изучает фреймворк по стейт-машинам и думает, как его прикрутить.

                                                  Это пост не предполагает ответ, просто пояснял, что я имел в виду.
                                                    0
                                                    Добавлю насчет сложности мерджа. Бывают проекты (я в подобных участвовал, так что не абстрактно), которые длятся, скажем год-полтора с участием 50-100 человек. При этом код системы может состоять из 0.5-1 миллиона строк и в ней меняется примерно 20-30% существующего кода, помимо добавления нового. Естественно, в ходе выполнения проекта продолжают выходить небольшие апгрейды к существующей продакшен-версии, а большой проект ведется целиком в бранче. Иногда бывает и по два таких огромных проекта параллельно, и потом надо это «слить» в транк. Так вот автоматом тут совсем не прокатывает, и на мердж уходит иногда месяц-два. Это что, тоже ошибки менеджмента? Нет, это реальности бизнеса компании…
                                                      –1
                                                      Да, ошибки менджмента. Если на обычный мердж уходит месяц извините))) Значит эта система контроля версий не подходит, либо необходима автоматизация, либо специальные люди (мантейнеры) и тд.
                                                        0
                                                        >Если на обычный мердж уходит месяц извините
                                                        Вы точно прочитали внимательно? Система в 1 миллион строк кода на С++. Многие компоненты в результате проекта изменены довольно сильно и не поддаются автоматическому мерджу (просто из-за конфликтов).

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

                                                          По поводу CVS не скажу ничего. Я с ним не работал потому что давно считаю эту систему умершей. Если вас не устраивает SVN есть еще например GIT и Mercurial. CVS позавчерашний день, и я удивлен что им еще кто-то пользуется. Не вижу ни одной причины на нем оставться, кроме лени что-то менять.
                                                            0
                                                            Хм… Прям обескуражили :) Хоть и добавил Вас в друзья, рискну поспорить.

                                                            Что означает «неправильная работа с мерджем» и как тогда правильно? Банальный пример конфликта: в проекте в бранче делается изменение в методе, а в транке в это время идет рефакторинг, в результате которого метод удален и заменен каким-то другим. Что здесь может поделать автомердж? И чем так поможет волшебный SVN? Вообще, в таких случаях самый быстрый способ — это сесть с каким-нибудь компарером типа Araxis Merge и вручную все это выправить.

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

                                                            А насчет SVN vs CVS. Может быть, SVN гораздо более эффективен, я про него знаю столько же, сколько Вы про CVS, хотя SVN часто на слуху. Но представьте большую компанию, весь код которой хранится в CVS со всей историей изменений, с кучей скриптов и макросов, завязанных на другие внутренние системы компании. Все это отлажено и работает отлично годами. Перевод на другую систему контроля версий с переписыванием всех скриптов и их отладкой и интеграцией займет, думаю, с полгода точно. Причем это будет работа для целой команды. Ведь еще надо протестировать, что ничего не упущено, что все работает как требуется и т.д. Учитывая стоимость одного разработчика для компании, скажем, 150,000 рублей/мес (половина — зарплата, вторая половина — налоги и другие выплаты в бюджет), за полгода для команды даже из трех человек получим 2,700,000 рублей. Плюс почти гарантированно в эту сумму не уложатся из-за каких-то неожиданных проблем. А что в результате получим? Более удобный интерфейс для разработчиков и, может быть, пара функций будет выполняться проще. И совсем не надо быть менеджером-таджиком, чтобы отказаться от этой затеи.
                                                              0
                                                              делать рефакторинг в транке? ужас…

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

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

                                                              И заметьте, вот вы говрите что не знакомы с SVN. Ну мне простительно мое незнакомство с CVS, ибо я не могу ковырять все допотопные системы. Но как вы можете утверждать о неизбежности проблем с переходом, даже не удосужившись в этом немного разобраться? Вы жалуетесь на проблемы с ветками, при этом даже не знаете как ветки организованны в других системах, SVN, GIT, Mercurial? Может там нет этих проблем? Может там существуют подходы, позволяющие их избежать?
                                                                0
                                                                Давайте опять по пунктам :)

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

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

                                                                Насчет быстрой конвертации в SVN. Я более чем уверен, что она есть. Но Вы, возможно, не поняли о чем я говорил. У нас, например, во время чекина в CVS выполняется множество сопутствующих макросов, которые вносят информацию о чекине в другие системы коллективной работы, применяемые в компании. И не так-то просто заставить все это работать с новой системой контроля версий. А кое-что может стать и невозможным из-за различий в подходах. Тогда неизбежно придется доделывать или менять другие системы компании и так по цепочке заменить все. Я боюсь себе представить, во сколько это обойдется. А потом, когда все наконец завершится, выйдет еще более новая версия с еще более правильной идеологией :)

                                                                Насчет SVN, GIT etc, я пока не услышал от Вас объяснения преимуществ их работы с ветками. Предлагаю написать статью. Но тогда придется хотя бы бегло изучить CVS…
                                                                  0
                                                                  >много частых мерджей станут равны по времени одному большому

                                                                  Это может в вашей CVS так. в SVN это далеко не так, и наоборот рекомендуется мержится и комитится как можно чаще. Это сэкономит массу времени.

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

                                                                  Правильно. Поэтому мержить надо из транка, а не в транк.

                                                                  >в компании из тысячи человек невозможно всем писать идеально

                                                                  Даже в компании из двух человек невозможно)))

                                                                  >Я боюсь себе представить, во сколько это обойдется

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

                                                                    0
                                                                    Насчет небольших частых мерджей готов согласиться. Поизучаю вопрос и best bractices в SVN.

                                                                    Насчет мерджей из транка в бранч — да, так и делаем периодически. Наверное, если делать чаще, то будет еще эффективнее. Но это надо доказать сравнением.

                                                                    Насчет скорости работы с ветками и т.д. Я почти никогда не ощущаю сложностей со скоростью работы с CVS. Репозитории у нас локальные по офисам с репликацией в один главный. К тому же у нас никто не колбасит код с такой скоростью, чтобы ему мешали те 30 секунд, которые нужны на чекин дневной порции кода :) Даже если мне надо делать чекин 10 раз в день — это в сумме 5-10 минут времени, большая часть из которого уходит на написание комментариев к чекинам.
                                                                      0
                                                                      >Но это надо доказать сравнением.

                                                                      Это доказывается логикой. Чем чаще мерж тем меньше конфликтов. на мерж тратится 15 сек. на разруливание конфликта от нескольких минут до бесконечности. Надо взять за правило
                                                                      1. часты комит. несколько раз в день. любое более или мение законченное изменение должно тут же комитится. не нравится длинную команду набирать, присовй элиас (или вы через гуи работаете?)
                                                                      2. частый мерж. закомитил, тут же смержился. в svn это делается простейшей командой, не надо номера ревизий запоминать все помнится автоматически.

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

                                                                        А вот это нам совсем не подходит. У нас любой код проходит предварительную инспекцию со стороны коллег. И только после этого можно чекинить. Не должно быть непроверенного кода в репозитории. К тому же иногда не полностью зачекиненный код ломает ночной билд. А на инспекцию тратится от нескольких часов до нескольких дней. Что делать в таком случае?

                                                                        Сложности с мерджем отчасти связаны с первой проблемой.
                                                                          0
                                                                          1. Какая проверка? Вы экономите на переходе на svn при этом впустую тратите людские ресурсы.
                                                                          2. Для того что бы непроверенный код не попадал в ночной билд и существуют ветки. Закомитился, и проверяй сколько влезет. Проеврил, прогнал тесты комить в билдовую ветку.

                                                                          щас я вас сэконосмлю несколько миллионов)))
                                                                            0
                                                                            Хм… А Вы слышали что-нибудь про процессы разработки и стандарты качества? PSP, CMM и т.д. Инспекции кода не я придумал. Кратко описывал это здесь: habrahabr.ru/blogs/arbeit/46495/
                                                                              0
                                                                              я к тому что частый комит и мердж никак не мешает инспекции кода. хотя и сама инспекция это бред. есть тестирование, это да, это нужно. но инспектировать код не нужно.
                                                                              1. нужно избегать говнокодеров еще на этапе собеседования
                                                                              2. плохо написанный код, если при этом написаны тесты со временем вылизывается. это называется TDD. А если вы дрожите деньгами, вам просто необходим принцип минимализма. То есть все что требуется от кода это то что бы он выполнял поставленную задачу. НО это только в том случае если у вас в целом все процессы верные, если у компа не говнокодеры, если пишете юниттесты, если код изначально хорошо структурирован… то есть правильно поставленная работа не требует контроля именно кода. но это не отменяет необходимость его тестирования, что невозможно без комита, иначе откуда тестеры его возьмут
                                                                                0
                                                                                Вы описали идеальную компанию с идеальным продуктом и идеальными процессами. Такой компании не то что инспекции, ей и тестирование не нужно. Но ведь где-то же должны получать опыт все Ваши художники программирования :) Поэтому нет ничего оскорбительного, если на ваш код внимательно посмотрит хороший архитектор с опытом работы в десяток лет, выскажет замечания и укажет на дефекты.

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

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

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

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

                                                                                    Про XP мы подумываем, но пока никак не соберемся применить. Тема однозначно интересная и многообещающая.

                                                                                    Еще постараюсь до написания статьи почитать про SVN. Если знаете какие-либо качественные обзорные статьи (не много! :) — буду благодарен.
                                                                                      0
                                                                                      ну извините за нескромность, но могу порекомендовать свои :)
                                                                                      habrahabr.ru/blogs/development_tools/45203/
                                                                                      habrahabr.ru/blogs/development_tools/45222/

                                                                                      хотя лучшая статья это svnbook ;)
                                                                                        0
                                                                                        Прочитал Ваши статьи и немного посмотрел svnbook. Честно говоря, не вижу ни одной вещи, которой нет в CVS. Абсолютно та же система работа с ветками. Есть одно различие, которое у нас очень легко решили. В SVN, как я понял, при любом комите обновляется ревизия всего репозитория, что удобно. Можно тогда взять код по любой ревизии и сравнить, скажем, пару соседних комитов. У нас это решили так: в WinCVS добавлен макрос, который при комите просто выставляет новый тэг на репозиторий. Вот и все отличия, которые я вижу. Поэтому абсолютно не вижу смысла переходить нам на SVN.
                                                                                          0
                                                                                          Да, ну и, возможно, еще один плюс: SVN развивается, а CVS уже давно не обновлялся. Но работает он стабильно и веских причин обновлять что-то я не вижу. Вот если появится что-то принципиально новое и удобное, тогда есть смысл подумать о переходе.

                                                                                          Кстати говоря, я почитал комментарии и вижу, что Вы так же относитесь к GIT, как я к SVN, хотя люди, казалось бы, аргументированно объясняют преимущества GIT. В общем, просто мы привыкли к разным системам и абсолютно идеальной системы для всех не может быть в принципе :)
                                                                                            0
                                                                                            я так и знал что вы это заметите :) Но дело в том, что после этих комментариев я начал использовать меркуриал в одном проекте, а недавно мне оне популярно объяснили что оказывается в другом моем проекте, который опен сорс, мне нужен GIT, но все не доходят руки под него проект перевести. Но то что это нужно сделать я не сомневаюсь. То есть скепсис понятен, и это нормально. А вот упертость это уже плохо.
                                                                                            0
                                                                                            ok.
                                                                                            а есть ли в CVS Externals Definitions?
                                                                                            как насчет отсутвия Merge tracking?
                                                                                            как вы думаете почему даже такой старый и большой проект как FreeBSD таки перешел на SVN?
                                                                      0
                                                                      Статью я писать не буду, потому что она неактуальна. Все умные люди давно перешли на более совершенные системы контроля версий, и мало кому нужно доказывать их приемущества.
                                                                        0
                                                                        Ок, пойду говорить своим менеджерам, что они неумные люди ;-)
                                                                0
                                                                Если интересно, то тут есть и про svn, и про cvs:
                                                                en.wikipedia.org/wiki/Comparison_of_revision_control_software

                                                                Самый большой плюс svn по сравнению с cvs — наличие atomic commits, и гораздо более стабильный и ловкий merge, не оставляющий мусора в файле. Плюс в целом быстродействие по сети заметно выше.

                                                                Из минусов svn (или недоплюсов) по сравнению с более поздними, такими как git, bzr или hg, — rename файла, хоть и автоматизирован, но по-прежнему через «не хочу», с удалением старого и добавлением нового (история изменений теряется); история мержей не хранится, так что по невнимательности легко можно смержить одну и ту же ревизию несколько раз :)

                                                                P.S. Тот же TFS отслеживает такой неприятный момент (хотя в режиме baseless merge карты в руки — можно что угодно с чем угодно мержить)
                                                                  0
                                                                  вы ошиблись. начиная с версии 1,5 svn хранит историю мержей
                                                                    0
                                                                    Если вы обратили внимание, то я там написал не только про merge history. Так что по-моему, вы обобщаете.

                                                                    Svn движется в сторону git в плане merge, это не может не радовать. Тем не менее, даже в 1.5 работает далеко не идеально. Те же tree conflicts более-менее корректно резолвятся только в 1.6.
                                                              0
                                                              sse
                                                              zakhars

                                                              Это всё называется Форк. И это 100% просчёт менеджмента и архитектора.
                                                                0
                                                                Очень хорошо.
                                                                Давайте, я с вами соглашусь. Предположим, архитектор просчитался указанным образом — ну, с кем не бывает, от ошибок никто не застрахован ;)

                                                                Что делать дальше — смержить-то надо? 90% вероятности того, что художник закатит истерику «вот, вы меня не послушали, а теперь такая ж*па, и поэтому я не буду разгребать ваше гуано».

                                                                А смержить-то — все равно кому-то надо :-P
                                                                  0
                                                                  ну так пусть тот кто ошибся тот и мержит. или выписать художнику премию за то что был прав.
                                                                    0
                                                                    Тот, кто виноват, давно уже не работает, потому что понял, чем пахнет то, что он натворил :)

                                                                    А премию художнику выпишем обязательно. По печени, бгг :) Потому что тут работа, а не танцы «я то не хочу, это не буду».

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

                                                                      вы наверное путаете работу и рабство.
                                                                        0
                                                                        Нет, это Вы, наверное, путаете меня и менеджера проекта; уверяю, я только технический лидер, и к распределению задач, ресурсов и приоритетов, не имею ни малейшего отношения :)
                                                                          0
                                                                          если вы технический лидер, то именно вам иделать. не ПМу же ветки мержить, не так ли?
                                                                            0
                                                                            Не, не так ) Работу должен делать тот, кому назначили делать эту работу. У нас не Индия, каст нет. Если его моральные принципы запрещают ему заниматься этим, пусть меняет — либо принципы, либо работу.

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

                                                                            Я уже написал ниже про «истинного» художника. Надеюсь, в своем изложении вы имели в виду именно его, а не летуна-белоручку.
                                                                    0
                                                                    Ваши проблемы. Сам себе злобный Буратино. Менеджмент — в первую очередь ответственность.
                                                                    Разгребать чужое гуано иногда сильно надоедает. Подумайте, стоит ли снижать мотивацию эффективного сотрудника? Или лучше дать ему нормальную задачу, а гуано пусть разгребает Джамшут. Ему всё равно где копать.
                                                                      0
                                                                      Мне все равно, кому и что надоедает. Я в такой ситуации тоже не собираюсь выступать в роли Джамшута только потому, что кто-то капризничает громче, чем я:)

                                                                      Вернее, так:
                                                                      1. Джамшут меееедленно, печально и безынтересно прожует и выполнит работу;

                                                                      2. «Художник» скажет «идите нах, моя гениальность не стоит того, чтобы тратить ее на то, чтобы проект заработал»;

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

                                                                      P.S. Да и что такое «нормальную работу» художнику? Разве приведение проекта в приличное состояние — это не нормальная работа? Что еще надо вдобавок — пиво, девки, блэкджек?
                                                                        0
                                                                        Согласен. Но всегда хочется большего ;)
                                                                        > пиво, девки, блэкджек
                                                                        А почему бы и нет? :)
                                                                          0
                                                                          все дело в том если он уже говрил о том что нам нужны тестеры, и делал это на протяжении полугода, созывал всех в переговорную, твердил это менеджеру каждый день, а ему говорили «да, да ты прав», но их так и не появилось. И он уже в который раз после выгрузки сидит все выходные и вылавливает баги, о которых почему то никто до выгрузки так и не слышал.
                                                                            0
                                                                            Тестеры есть, но если бы он говорил, как улучшить процесс, я бы первый его поддержал :D

                                                                            Но на практике почему-то оказывается, что он рапортует, что багов нет и все у него работает, потому что снизойти до unit-testing-а ему не позволяет я не знаю что, а найденные за ним баги отказывается фиксить с пометкой «отклонено, неинтересно» :D

                                                                            Я же говорил, у нас разное понимание художника, видимо ) Тот тип художника, о котором я говорю, даже Doxygen-комментарии для публичного API считает рутиной :D
                                                          –2
                                                          дело в том что IT-таджик вообще не будет использовать ветки)))
                                                            0
                                                            >> Это неверно. Наоборот трудности мотивируют. А если это не так то это никакой не художник.

                                                            С этой фразы я понял, что у нас, видимо, разное понимание «художника». *Пошел перечитывать обе статьи*
                                                              0
                                                              IT-таджик (в Вашем определении) будет делать то, что ему скажет менеджер. Если в компании используются ветки, то он и мердж будет делать.
                                                                0
                                                                А если менеджер тоже тоже таджик? А если менджер вообще не знает что такое svn?
                                                                  0
                                                                  А почему только SVN? :) Чем так CVS, скажем, не устраивает? А по существу, мердж зачастую весьма нетривиальная операция, о чем я написал чуть выше.
                                                                    0
                                                                    потому что cvs это позавчершний день. Глупо сейчас его использовать.
                                                                      +2
                                                                      Офигеть-довод по существу (;
                                                                        0
                                                                        нормальный довод. глупо использовать что-то старое если есть новое. я понимаю если это новое только появилось и непонятно как будет развиваться. но svnу сто лет. cvs это архаизм.
                                                                          0
                                                                          ой да ладно.
                                                                          можно подумать у вас на дестопе виндоуз 7/последняя убунта, кодите вы в последней версии IDE (ганимед/ZDE)?

                                                                          выбор новой технологии должен быть обусловлен только преимуществами, которые она дает. Если преимущества сводятся к «новее» — это не довод убивать время на перенос проекта с одного на другое.
                                                                            0
                                                                            убунта последняя. а смысл старую испаользовать? Кодю да, под полседней верисией, а было что и под бетой кодил, это когда в нетбинсе серьезно улучшили поддержку php

                                                                            и давайте не будем устраивать холивар. если есть две системы, и одна из них новее, при этом обе удовлетворяют задачам, надо переходить на более новую. я не говрю что сразу кидаться сломя голову, но по карйней мере сильно не затягивать.
                                                                              0
                                                                              да что там svn vs cvs! Как только появился svn 1.5 тут же заставил админа её поставить, хотя на серверах центос, и в репозиториях новые версии не появляются. то есть ему бедному пришлось ручками рпмку собирать. ну ничего. справился, и в награду мы получили выигрыш во времени при мерджах, и избавились от гемороя. хотя ведь старый свн по сути все наши задачи выполнял нормально.
                                                                              0
                                                                              Если что то работает и всех устраивает, зачем ставить новое? Новое ради нового это нонсенс.
                                                                                0
                                                                                если у вас жигули, почему вы хотите БМВ? вам нужно передвигаться, и жигули это умеют.
                                                                                  0
                                                                                  Ок, повторю еще раз. Если что то работает и ВСЕХ УСТРАИВАЕТ, зачем ставить новое? Если у меня будет жигули, то меня это заведомо не будет устраивать.
                                                                                    0
                                                                                    ну а если у вас будет скажем бмв, то вы конечно же откажетесь от бэнтли :)
                                                                                      0
                                                                                      тем более что не устраивает. человек же пишет что месяцами они мержат ветки.
                                                                            0
                                                                            не только svn. я например сейчас использую mercurial в одном своем проекте.
                                                                          0
                                                                          Во всех компаниях в которых я работал ветки внедрял я. Без меня о них даже не задумывались. Все, начиная от менджмента и заканчивая программистами о них слышали, но думали что это им или не нужно или это что-то очень сложное. После внедрения веток, большенство разработчиков их не использовали если не проследишь за этим лично, и не протрахаешь все мозги «Вася, ты ветку завел?».
                                                                    –1
                                                                    >В любом проекте есть дефекты на любой его стадии

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

                                                                    >как только он сталкивается с трудностями, он бросает эту задачу

                                                                    Это неверно. Наоборот трудности мотивируют. А если это не так то это никакой не художник.
                                                                      +1
                                                                      трудности, связанные с багами — не мотивируют совершенно.
                                                                      0
                                                                      честно не понимаю почему вы считаете что художник так легко бросит свое детище. Я бы скорее предположил вариант крепко подумает, и предложит серьезную переделку дизаина проекта, которая должна будет вычистить множество багов, образовавшихся из-за постепенных внесений в проект.
                                                                        0
                                                                        > И когда его просят сделать мердж из бранча в транк (ну, перенести полезные изменения в побочной ветви) он говорит «это скучно и неинтересно заниматься этой рутиной, я не хочу это делать». Как быть тут?

                                                                        А зачем вам такие долгие бранчи, что их муторно мержить?
                                                                          0
                                                                          А почему вас это интересует? Разве ответ на этот вопрос поможет вам изменить мое мнение насчет художников?
                                                                            0
                                                                            Безусловно. Когда художник считает, что его заставляют делать херню, он всеми силами избегает этой работы.
                                                                            По моему мнению длинные бранчи с большими мержами — это не рутина, а самая настоящая херня.
                                                                              0
                                                                              Мы счас не стратегии мержа обсуждаем, а отношение «художников» к своей работе.

                                                                              Проблема в том, что нет гарантии, что проект _внезапно_ не «разонравится» художнику, и тот вдарит по тапкам. Проект уже неинтересен, и делать его «художник» не будет.

                                                                              Пример с мержем — просто иллюстратив, не более.
                                                                                0
                                                                                внезапно знаете что бывает? :)
                                                                                в реальности проект не может внезапно разонравится. вчера нравился а сегодня понял что херня. не бывает такого. обычно это происходит постепенно, и у этого есть причины. и чаще всего это ошибки управления.
                                                                                  0
                                                                                  Если разонравится, значит проект — действительно говно, и с этим надо что-то делать.
                                                                                  Так что настроение художника в таком случае выгодно использовать по типу канарейки в шахте ;)
                                                                        +2
                                                                        Если приходится править чужие баги в больших количествах, то, конечно, радостного мало. Но приходилось и приходится исправлять и чужие баги и свои и ничего, просто исправсяется баг с повышением надёжности, функционала и эффективности, от чего получается приличное удовлетворение.
                                                                        (себя считаю как раз художником в классификации данного поста)

                                                                        > Я сто раз слышал в такой ситуации «мне это неинтересно».
                                                                        И такое бывает, но это уже лень (или очень недостаточная финансовая мотивация), но это уже из другой оперы.
                                                                          +3
                                                                          Иногда баги бывают прикольными и их отладка настолько затягивает, а сколько всего узнаешь и вспоминаешь, что ощущение бешеной радости покруче чем от законченной задачи.
                                                                            0
                                                                            Угу. На деньги-то заказчика чего б не позатягиваться в баги…
                                                                  0
                                                                  > Нет. Естественное стремление вольных художников — бросать проект, когда баги начинаются.
                                                                  Я считаю себя художником. И для меня баги — тоже вызов. Поэтому я исправляю их быстрее кого бы то ни было (иногда шпыняешь тестера по поводу правильного оформления бага, а сам его уже давно исправил ;) ).
                                                                    0
                                                                    Рад за вас. У меня тоже так, только художником я себя не считаю.

                                                                    Что я делаю не так и как мне исправиться?
                                                                      0
                                                                      Делайте, что хотите, только не критикуйте ценности, которых у вас нет.
                                                                • UFO just landed and posted this here
                                                                    0
                                                                    Так это же хорошо)))
                                                                    • UFO just landed and posted this here
                                                                        0
                                                                        Нет. Это плохо. Это то, почему мы такие бедные, блин.
                                                                        Идея должна оплачиваться. Хорошая идея должна хорошо оплачиваться.
                                                                        Иначе будешь ценным только для себя любимого.
                                                                      0
                                                                      ИМХО хороший менеджер не может быть ни просто «таджиком» ни просто «художником» а должен сочетать эти качества вместе. Вы пробовали взглянуть на проблему со стороны руководства?
                                                                      На руководстве штат сотрудников, которые хотят получать зарплату, причем стабильно и много, офис, арендодатель которого тоже хочет кушать, и далее по списку. Для того что бы эти затраты нести необходима стабильность — «художники» в том смысле, который Вы вкладываете в это слово стабильность не могут обеспечить в принципе, как в прочем и «таджики». для успешного развития компании необходим баланс стабильности, что бы спокойнее спать, и иновационности, чтобы спокойно спать в долгосрочной перспективе, и любые перекосы в одну из сторон ничего хорошего компании не принесут.
                                                                        –6
                                                                        художники вполне могут обеспечивать стабильность и отсутвие перекосов. не надо думать что это всегда фанатики. но в терминах статьи таджик и художник это вещи прямо противоположные. нельзя быть одновременно плюсом и минусом.
                                                                          0
                                                                          нельзя дискретно разделять людей, тем более всего на две категории. каждый человек уникален.
                                                                          Я считаю что Вы видите картину однобоко. Конфигурация Работник-Руководство-Заказчик может стабильно сосуществовать только при одном условии — совместная работа приносит всем прибыль, и чтобы так и было, необходимо учитывать интересы всех сторон, что практически всегда заставляет кого либо подстраиватся под ситуацию.
                                                                          Вы же настолько эгоистичны, что не хотите даже видеть интересы других, а они далеко не всегда совпадают с Вашими (и с интересами описаных Вами «художников»)

                                                                            0
                                                                            совместная работа всегда приносит прибыль только одному — заказчику. всем остальным она приносит доход.
                                                                              0
                                                                              да ну? а прибыль разве не от размера дохода зависит?

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

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

                                                                                  >для получения дохода вкладывать средства не нужно
                                                                                  для того что бы доделать какой либо проект необходимо — заплптить персоналу, который над этим проектом работает, оплатить аренду помещения, текущие платежи такие, как телефоны, интернет, свет и пр. — это по Вашему не вложение средств для того что бы по окончанию проэкта получить доход, вычесть из него все расходы, оплатить налоги и с удовольствием посчитать ПРИБЫЛЬ?!

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

                                                                                  В энный раз повторюсь Вы смотрите на проблему только со своей точки зрения, и не хотите учитывать потребности заказчика, а в любом проекте главный именно он
                                                                                    –3
                                                                                    вы не поняли.

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

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

                                                                                        >Наибольшую прибыль ему смогут обеспечить только художники
                                                                                        наибольшую прибыль ему сможет обеспечить только его голова. К вам он обращается только за решением его, конкретной задачи. критерии при отборе исполнителей с точки зрения заказчика — решение ЕГО (ни в коем случае не вашей) задачи, стоимость ее решения, сроки. Если его задачу можно решить испульзуя уже что то готовое, пусть и такое, которое не нравится «художнику», то это проблеммы только художника, а никак не заказчика, зато повышается скорость разработки и уменьшается цена.
                                                                                        Поймите с точки зрения заказчика — вы должны сделать так как хочет он, а не так как думаете вы, в лбом случае в своей области он разбирется лучше вас, поэтому что бы такого заказчика привлечь и удержать ва просто необходимо иметь качества в первую очередь «таджика»
                                                                                          0
                                                                                          Цитирую википедию

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

                                                                                          Регулярное денежное пополнение может быть обычным окладом. Прибыль — всегда разница между затратами и доходом. Андестенд?

                                                                                          >с точки зрения заказчика — вы должны сделать так как хочет он

                                                                                          Правильно. Но сделать это можно разными путями. Художник выберет всегда наиболее оптимальный путь. Таджик наиболее простой (не значит быстрый)
                                                                                            +6
                                                                                            Цитирую Вашу статью в моем понимании «Я такой модный и самый умный, а все остальные дураки, и только я знаю как решить все проблемы»
                                                                                            Хочу отметить — современное предприятие — это сложнейший механизм. и любой в этом механизме (будь то ген. директор или сантехник Вася) всего лишь шестеренка. этот механизм будет работать нормально только тогда когда каждая из шестеренок выполняет свою и только свою функцию хорошо.
                                                                                            как только какая либо из шестеренок начинает прыгать туда сюда и пытатся заменить собою весь механизм — этот механизм начинает работать только хуже.
                                                                                            Это я к тому, что каждый должен делать свою работу. и благо работы сейчас много (да я слышал про кризис), так что большинство может найти себе работу по вкусу и способностям.
                                                                                            Вам же в этой ситуации сложнее, потому что вы считаете истинно правильным только свое личное мнение и я сомневаюсь, что можете правильно оценить свои силы.
                                                                                            Я тоже по натуре художник и меня просто бесит тупая монотонная работа, но иногда оптимальное решение это сделать что то монотонно, а не изобретать велосипед или искать приключений на свою задницу, но вы этого не поймете.
                                                                                              0
                                                                                              >всего лишь шестеренка

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

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

                                                                                                  вот и думайте что лучше, когда каждый = шестренка, упорно пытающаяся делать свою работу, либо когда каждый = часть сложного организма, способного гибко реагировать на ситуацию. И что лучше, когда кадый орган такого организма может выполнять только свою работу, или когда каждый способен подменить или помочь соседу, послать сигнал о проблемах, и минимизировать вред, дожидаясь решения.
                                                                                                    +4
                                                                                                    ключевое слово в вашем коментарии — подстраиватся, вы же категорически не хотите ни под кого подстраиватся.
                                                                                                    Собрав несколько таких «художников» как вы получим классических лебедя рака и щуку — все хотят своего и в гробу видали интеремы других.
                                                                                                    Дальнейшую дискуссию считаю бессмысленной.
                                                                                                    Как нибуть когда подросту напишу отдеьлно про эту ситуацию со стороны заказчика, и то как все таки бесит когда вместо самоката за 100 ден ед, который действительно нужен, тебе в итоге пытаются всучить космический корабль за 100000000000 мотивируя это только тем что он круче и сделан с применением самых передовых технологий.
                                                                                                      0
                                                                                                      >не хотите ни под кого подстраиватся

                                                                                                      Да откуда вы это взяли?
                                                                                                      +5
                                                                                                      а вы подумайте что будет, если ваша рука, схватившая горячую сковородку будет ждать когда мозг решит что же делать.
                                                                                                      Если чего, в данном случае решение принимается в головном мозге. :)
                                                                                          +1
                                                                                          этим я хочу сказать что «художник» должен творить, а в суровой рыночной реальности, победит ремесленник с чертами художника, который сможет делать так как ему говорят, при этом только в действительно необходимых ситуациях советующий заказчику как необходимо поступить
                                                                                            0
                                                                                            Это утопия манагеров нижнего звена.
                                                                                            Так не бывает.
                                                                            +11
                                                                            >1.Менеджмент, состоящий из IT-художников стремится выполнить любую задачу быстро, как только может.
                                                                            Вместо того, что бы заниматься реализацие задачи, которая уже горит заказчику «художники» будут вдумчиво курить новую версию фреймворка.
                                                                            Не потому что старая была плоха, просто писать на старой — скучно!
                                                                            >2.Художники не любят рутины. А правка багов это рутина. Потому естественное стремление — багов не допускать.
                                                                            А когда баги вдруг все-таки случаются художники очень-очень удивляются, ведь они творцы! Багов не допускают! А нормально протестировать проект — лень, потому что это же рутина.
                                                                            Вместо этого лучше почитать про новый фреймворк, и пофиг что из-за этого одного бага проект заказчика навернулся и фирмы вылетела в копеечку. Творец уверен — в перспективе он принес бы большую прибыль.
                                                                            3.Как я и написал выше, динамика проекта это главное. Поэтому внесение изменений это не зло, это благо.
                                                                            Очень удобно, придти на новое место, назвать всех «таджиками», себя «д'артаньяном» и предложить переписать проект с нуля. Это постоянное желание «творцов» — переписать с нуля.
                                                                            Вот только заказчику нужно совсем не это, заказчику нужна скорость реакции. И это именно та причина, почему «таджики» пробиваются в руководство, а «творцы» нет.

                                                                            P.S. Напомнило из Пелевина «Криейторы нам нафиг не нужны! Нам нужны творцы!».
                                                                              0
                                                                              В оригинале не «нафиг», но цитата в самое яблочко :)
                                                                                0
                                                                                Я знаю, но не решился матом на хабре (:
                                                                                –1
                                                                                >Вместо того, что бы заниматься реализацие задачи, которая уже горит заказчику «художники» будут вдумчиво курить новую версию фреймворка.

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

                                                                                >А нормально протестировать проект — лень

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

                                                                                >Это постоянное желание «творцов» — переписать с нуля.

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

                                                                                  >И получат по шапке за срыв сроков. А это не в интересах художников
                                                                                  Во-первых как получат? Лишат премии? Вы сами писали, художникам она не нужна. Поругают? Художник напишет пост зла о том как его не понимают и уйдет в другую фирму.
                                                                                  Во-вторых в интересах художника — сделать Вещь, дела менеджмента его интересуют меньше всего.

                                                                                  >Этим должны заниматься тестеры.
                                                                                  Есть еще маленькие проекты, где тестеров, увы, нет.

                                                                                  >Это желание не следствие художников, а следствие того что над проектом работали таджики под управлением таджиков
                                                                                  По моему опыту, когда проект активно меняется в течении нескольких лет он физически уходит далеко от самых смелых расчетов создателей. И это — нормально.
                                                                                    0
                                                                                    >Во-первых как получат?

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

                                                                                    >в интересах художника — сделать Вещь, дела менеджмента его интересуют меньше всего

                                                                                    Вы слишком узко пониматете что такое менджмент.

                                                                                    >Есть еще маленькие проекты, где тестеров, увы, нет.

                                                                                    Это проблемы этих маленьких проектов.

                                                                                    >в течении нескольких лет он физически уходит далеко от самых смелых расчетов создателей

                                                                                    Это только следсвие работы таджиков и плохого управления проектом.
                                                                                      0
                                                                                      когда вы уходили из своих проектов, вы все их завершали?
                                                                                      Вы с самого начала вели проект больше двух лет? Ядро ни разу не переписывали?

                                                                                      Только при положительном ответе на все три вопроса имеет смысл что-то обсуждать. Вы берете ситуацию «если бы в тиме и в менеджменте были бы одни такие программисты как я».
                                                                                        0
                                                                                        1. Не все. Радости это не приносило.
                                                                                        2. Больше двух лет нет. Примерно год и девять месяцев.
                                                                                        3. Переписывал, но этого требовало развитие проекта. Кстати получилось очень удачно, и проект работает удачно до сих пор.
                                                                                          +1
                                                                                          О! Это я и хотел услышать.
                                                                                          Теперь сравните эти ответы с вашими же словами выше:
                                                                                          1. Уход у другую компанию — неудача.
                                                                                          2-3. Если заказчик изначально возьмет художников, то у новых художников желания переписать проект не возникнет.

                                                                                          И еще раз говорю — это нормально. Это нормальный цикл развития продукта. И совсем не значит что те кто начинали продукт «таджики».
                                                                                            0
                                                                                            1. естественно неудача. неудачи у всех случаются. но все стараются их избежать. иногда не удается.
                                                                                            2-3. стоп, выразился не точно

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

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

                                                                                    Обычно у джамшутов скорость реакции намного ниже, потому что:
                                                                                    а) «ну их нафиг с их требованиями»
                                                                                    б) интриги -> недостаток передаваемой информации -> отсутствие обратной связи
                                                                                    в) общий непрофессионализм в связи с отсутствием интереса к саморазвитию
                                                                                    0
                                                                                    >Сам проект, если он вялотекущий, может надоесть, потому менеджмент стремится сделать проект динамичнее, что бы он развивался быстро, быстрее появлялись новые задачи

                                                                                    Не боитесь, что таджики, любящие размеренность и покой, перегорят от темпа, задаваемого менеджером художником?
                                                                                      –2
                                                                                      всегда будет достаточно рутинных задач. В крайнем случае ничего страшного, пусть ищут себе место где размеренность и покой. В хорошем проекте не должно быть покоя, а должна быть динамика и драйв.
                                                                                        +3
                                                                                        черт, я таки таджик :)
                                                                                      0
                                                                                      Как-то всё сильно идеализировано, нет в жизни такого. И художникам приходитя заниматся рутиной, когда это менеджеры (особенно когда менеджеры), и у «таджиков» проскакивает кретив
                                                                                        +1
                                                                                        > Став начальником, это чувство остается.
                                                                                        Став начальником художник перестаёт быть художником ) А чувство может притупиться до нуля.
                                                                                          0
                                                                                          Откуда такие выводы?
                                                                                            0
                                                                                            Личный опыт.
                                                                                            Сейчас я уверен, что мне лучше либо работать «на дядю» на должности «художника» либо работать на себя. Но уж никак не быть «начальником под управлением дяди».
                                                                                            (сейчас я уже давно не «начальник» =)
                                                                                              0
                                                                                              может быть вы и правы, хотя я всегда с интересом брал на себя работу менджмента, когда это удавалось. хотя менджмент всегда старался поставить меня на место, либо воспользоваться моей добротой. в первом случае боялись конкуренции, ибо прогресс был очевиден. во второй радовались что можно ничего не делать, а заказчик думает что прогресс это их заслуга)))
                                                                                                0
                                                                                                > всегда с интересом брал на себя работу менджмента
                                                                                                Согласен. Это интересно!
                                                                                                Но всё упирается в рамки. Ваши термины «художник» и «таджик» — это описание границ возможного поведения: «Художник» делает что хочет, а «Таджик» то, что ему говорят. «Менеджер среднего звена» — это «СуперТаджик», он отличается от обычного тем, что он начальник. И всё )
                                                                                                  0
                                                                                                  «Менеджер среднего звена» может быть и СуперХудожником.
                                                                                                  • UFO just landed and posted this here
                                                                                                      –2
                                                                                                      Год назад я был убежденным атеистом и эволюционистом. Сейчас я верующий креационист. А вы говорите невозможно)))
                                                                                                        +1
                                                                                                        с годами люди тупеют…
                                                                                          +1
                                                                                          Складывается впечатление, что автору никогда не доводилось сталкиваться с по-настоящему талантливыми управленцами, как проектного так и корпоративного уровня.
                                                                                            –1
                                                                                            доводилось. могу вспомнить даже двоих, и оба художники.
                                                                                              –1
                                                                                              А менеджер он джумшутом быть не может. Управления без творчества не получается =) Я к тому что какой то совсем пессимистичный взгляд на нашу индустрию получается. По моему мнениею, важно вселить в команду веру не только в то что проект которым она занимается будет успешен (премии, профессиональный рост, признание какое-никакое), но и в то что за ним обязательно последует еще лучший проект. Можно конечно называть это эксплуатацией природного энтузиазма «художников» и корысти «джумшутов», но в конце концов перед нами стоит одна простая задача — делать софт, который будет удовлетворять заказчика.
                                                                                                0
                                                                                                поверьте, управление может быть без творчества. причем это происходит чаще всего.
                                                                                                  0
                                                                                                  именно.
                                                                                                  хрен найдёшь уже фирму с нормальным менеджментом.
                                                                                                  везде кланы джамшутов, бардак и убытки.
                                                                                                  или может я просто плохо искал?
                                                                                            0
                                                                                            «Художники» бывают разные. Я лично считаю за художников тех, кому нравится сам процесс. А они часто не особо стремятся к финальному результату. Им бы все что-нить улучшить. Таких надо все время одергивать, если они сами еще не научились =)
                                                                                              –2
                                                                                              таких не бывает. это стеореотип. скорее это таджики которым не хочется работать. вот они и эмитируют какую-то деятельность, прикрывая это типа улучшением. для худолжника всегда важен результат. и если долгое время результата нет, он не может быть удовлетворен.
                                                                                                +3
                                                                                                Такие есть, поверьте. Я однажды писал проект с таким. Ему периодически приходили идеи улучшения архитектуры и он переписывал половину проекта(не маленького, кстати). И такое было не раз. Притом что проект был не коммерческий, так что симулировать бурную деятельность было бесполезно =)
                                                                                                  0
                                                                                                  Да-да… Знаем таких. Для коммерческой стороны дела конечно катастрофично, но в долгосрочной перспективе метод «до основанья, а затем» иногда приводит к интересным технологическим прорывам местного значения.
                                                                                                    0
                                                                                                    это недостаток знаний/ума
                                                                                                    когда-то я тоже стремился переписать свой же код спустя полгода. Потому что постоянно развивался и понимал спустя время свои ошибки. Но сейчас меня мой код вполне устраивает. Я пишу сразу хорошо, и желания переписывать у меня нет.
                                                                                                      0
                                                                                                      Скорее недостаток опыта, но бывает такой тип людей которых принято называть перфекционистами — это как тот случай
                                                                                                        0
                                                                                                        Говорят, что если спустя пол года вас устраивает ваш код, значит либо вы достигли совершенства, либо не выросли в профессиональном смысле за эти пол года.
                                                                                                          0
                                                                                                          неверно говорят. было несколько этапов когда код хотелось переписывать каждые пол года. я так и делал. но сейчас у меня есть фреймворк, который меня устраивает, но не значит что я достиг совершенста. просто он меня устраивает и все. его достаточно для моих задач, делать его совершеннее нет смысла
                                                                                                    0
                                                                                                    > Я лично считаю за художников тех, кому нравится сам процесс. А они часто не особо стремятся к финальному результату.

                                                                                                    Это не «Художники», это — «Лузеры»
                                                                                                    +8
                                                                                                    >> Итак, можно поделить IT специалистов на IT-таджиков и на IT-художников
                                                                                                    Я целиком и полностью согласен с Джоелем Спольским — спец может быть умным и может делать дела. Художник в вашем понимании по определению делать второе не в состоянии (читаем про рутину и баги в топике — обычный процесс любого программиста). Ему важно что-то сделать на модных рюшечках, «предоставить инфраструктуру», как они любят говорить (а дальше с багами вы сами ебитесь).

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

                                                                                                    Вообще, с делением на два вида я бы не соглашался. Как минимум любого разработчика можно классифицировать на четыре типа:
                                                                                                    1) те, кто умен, и кто может доводить дела до завершения
                                                                                                    2) те, кто умен, но не может доводить дела до завершения
                                                                                                    3) те, кто не умен, но может доводить дела до завершения
                                                                                                    4) те, кто не умен, и не может доводить дела до завершения

                                                                                                    Как правило, тип 3 и 4 не проходят испытательный срок. Но тип 3 был очень распространен в докизисные времена, и, судя по всему, раз автору удалось поработать в РБК-Софте, то таджики — как раз про них.

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

                                                                                                    И еще совет — МакКоннела прочитайте. Ну честно, прочитайте МакКоннела. Если читали, перечитайте еще раз, более вдумчиво — там с цифрами, с толком, с расстановкой. Как раз про то, что вы тут говорите, но с совершенно другими выводами. Может, поймете что.
                                                                                                      –6
                                                                                                      >Ему важно что-то сделать на модных рюшечках

                                                                                                      Это бред! Вы ничего не поняли.

                                                                                                      >Баги искать не хочет, тестировать не хочет

                                                                                                      И правильно! Этим должны заниматься тестеры.

                                                                                                      >В общем, иметь таких художников на проекте — врагу не пожелаешь.

                                                                                                      Да вы же сами во всем виноваты! С собой разберитесь, прежде чем на других вину спихивать.

                                                                                                      >оработать в РБК-Софте

                                                                                                      Я не работал в РБК-Софте. Это другое подразделение холдинга. И ум тут не причем вообще.

                                                                                                      +9
                                                                                                      Хорошо, наверное, жить в черно-белом мире. Просто, и все схемы строятся логичные-логичные.
                                                                                                        0
                                                                                                        Некоторое в этом мире дискретно. Часто это касается человеческой логики.
                                                                                                        0
                                                                                                        Знаете, я подумал что главный вопрос в том с какой стороны баррикад смотреть.
                                                                                                        Давайте сделаем простой опросник. Я отпишу две ситуации, отдельно для тимлидов и отдельно для разработчиков. Вам я предлагаю плюсовать за тот вариант, который вам больше нравится.

                                                                                                        Большая просьба не минусовать (иначе результат будет не точным) и не голосовать за оба варианта, т.е. Вы или программист или тимлид (как в жизни).
                                                                                                          0
                                                                                                          1. Вы — тимлид на фрилансе. Вам предложили сделать интернет-магазин, с очень сжатыми сроками (2 недели, скажем).
                                                                                                          Вы можете взять в помощь двух программистов, кого вы выберете?
                                                                                                            0
                                                                                                            1.1. Двух «художников»
                                                                                                              +10
                                                                                                              1.2. Двух «таджиков»
                                                                                                              0
                                                                                                              2. Вы — программист в тиме из трех человек, задача сделать тот же магазин в те же сроки. С кем бы вы хотели работать?
                                                                                                                +4
                                                                                                                2.1. С «художниками»
                                                                                                                  +3
                                                                                                                  2.2. С «таджиками»
                                                                                                                  +1
                                                                                                                  Идея не очень хорошая. По одной простой причине. Вы не сможете понять причины выбора. Я сразу скажу что всегда предпочту работу с художниками.

                                                                                                                  Но вообще тема статьи немножно все таки другая. В неё говорится о менджменте.
                                                                                                                    0
                                                                                                                    Про причины выбора можно посмотреть в комментариях.
                                                                                                                    Здесь же мы видим обобщения — работать с художниками в одном тиме народ не против (4/3), что не говорит практически ни о чем.

                                                                                                                    Но вот при жестком дедлайне никто (!) не хотел бы художником руководить.
                                                                                                                    И это именно то, с чем приходится сталкиваться IRL.
                                                                                                                    Потому что в критический момент может оказаться проще написать самому, чем долго спорить о преимуществах SVN перед CVS.
                                                                                                                      0
                                                                                                                      вы не знаете что такое художник. это не тот человек кто несмотря ни на что хочет пробовать новые феньки. я уже устал говрить что для художника главное что бы его работой были довольны. и в дедлайн он прекрасно понимает что единственный путь это сдать проект вовремя. адекватный человек не будет переписывать всеь код зная что завтра проект должен быть на продакшене и приносить бабло. и не будет вдруг в последний день проекта менять cvs на svn. Это глупо просто.

                                                                                                                      поймите художник это не синоним фанатика.
                                                                                                                        0
                                                                                                                        моя любимая фраза, которую я часто повторяю «не доводи до фанатизма»
                                                                                                                          0
                                                                                                                          Я отвечу с позиции тимлида — с художниками.
                                                                                                                          Тупо потому что эффективнее. Тем более в сжатые сроки.
                                                                                                                      –1
                                                                                                                      Цитату «Пиление различных бюджетов это древняя русская национальная забава!», если Вы не против, добавлю в список любимых цитат. Так не против?
                                                                                                                        0
                                                                                                                        Пожалуйста)))
                                                                                                                      • UFO just landed and posted this here
                                                                                                                          –4
                                                                                                                          1. Конечно я упростил. Но я считаю что все люди стремятся к этим двум типам.
                                                                                                                          2. правильно чувак уходит. от людей которые считают что sql + jdbc это хорошо, бежать надо как от огня. думаю вы объясняете свою лень и глупость тем что зарабатывает бабло для заказчика. ну чтож, флаг вам в руки. только вы как были говнокодером так им и останетесь.

                                                                                                                          >И в итоге имеет код, который понимает только большой специалист

                                                                                                                          Спешу вас разочаровать. Я не встречал программиста, для которого было бы проблемой понять подобный код. Из этого вывод что не специалист нужен а мозги. Когда их нет, и букварь сложной книгой покажется, так может отменим первый класс?
                                                                                                                          • UFO just landed and posted this here
                                                                                                                            • UFO just landed and posted this here
                                                                                                                                0
                                                                                                                                И знаете, как пофиксал?

                                                                                                                                catch (StackOverflowError)

                                                                                                                                нормальное временное решение. если он конечно понимает что это злостный костыль и в отпуске лучше не задерживаться, либо попросить коллегу исправить (поставив потом много пива). Если не понимает, и думает что это нормально, то конечно неуд. Но все мы когда-то чего-то не знали. Главное что он хочет знать.
                                                                                                                                • UFO just landed and posted this here
                                                                                                                                –2
                                                                                                                                нет, я так не считаю. конечно же не во всех, и даже считаю что хебернейт не очень хорошая штука для малых и средних проектов. Тут гораздо удобнее будет что-то на основе паттерна Активрекорд. Но заметьте, я ни слова не сказал что эта штука для меня слишком сложная, не разберешь ничего и тд. И уж точно в страшном сне я видел чистый sql в контроллере. спасибо, проходили.

                                                                                                                                но повторяю, есть нормальные критерии выбора того или иного решения. возможно в вашем случае лучше было бы выбрать что-то другое. но вы же сказали «понимает только большой специалист». То есть это для вас проблема. То есть по сути вы говрите «у нас не хватает мозгов для того что бы это понять, поэтому это плохо». Так вот, плох не хибернейт, а отстувие у вас мозгов.
                                                                                                                                • UFO just landed and posted this here
                                                                                                                            +5
                                                                                                                            В первом топике я постарался серьёзно подискутировать по данной теме. Увидев этот топик, испытал небольшое удивление — неужели снова будет о плохишах «IT-таджиках» и молодчагах «IT-художниках»? Казалось бы, что тут ещё можно нового придумать? Оказалось, что можно. Прочёл до конца, опять написал длинный комментарий. Хорошо, что нажал кнопку «предпросмотр». Потому что ничего очень нового в этом комментарии не оказалось. Всё те же вопросы, всё те же «не согласен». Стёр. И написал вот что:

                                                                                                                            1. Почему таджики и художники? Почему такое странное противопоставление? Да, я прочитал постскриптум. И всё же. Да, таджики едут в Москву работать. А задумывались ли Вы, почему? Да, именно, в Москве больше платят. Несоизмеримо больше. Так что же, не ехать теперь? Или Вы осуждаете всех тех, кто переезжает в другой город/страну, так как там они нашли более хорошую (высокооплачиваемую) вакансию? Ну тогда можете смело поменять на IT-американцев. В Америке, например, переехать в другой город/штат в поисках работы — обычное дело. Ладно, разобрались с таджиками и причинами их переезда. Почему в противовес алчным таджикам Вы ставите художников? Художник, в первую очередь, творит от души. Делает то, что ему нравится и делает так, как нравится. Захотелось написать картину, используя только жёлтую краску, и напишет… Только вот делает он это для себя. А потом, при необходимости/возможности, продаст эту картину. Зачем же художник осознанно идёт туда, где ему ставят задачу, да ещё и ограничивают сроками и средствами? Творчество не терпит приказов и слов «надо».
                                                                                                                            Я не хочу домысливать за Вас, но вывод начал напрашиваться уже после первой статьи. Вы мните себя художником, так как Вам скучно выполнять рутинные задачи, хочется «творить» и вообще художники офигенные ребята. А из-за того, что общество не принимает эту позицию и не приемлет подобного, конфликт. И конфликт решается на глазах хабра. Ай-яй, эти нехорошие «IT-таджики», художникам дорогу!

                                                                                                                            2. Где и в каких условиях Вы наткнулись на описываемых Вами IT-таджиков и непроглядно тупых менеджеров? Где водятся такие заказчики, которые спокойно смотрят, как проект затягивается на годы?
                                                                                                                            Не знаю, может мне повезло больше, но там, где я работаю, принята оплата человекочасов. Перед началом разработки некоего функционала, заказчику предоставляется план выполнения работ, оценка трудозатрат (в человекочасах), стоимость человекочасов для определённых типов задач. И всё. И заказчик заплатит определённую сумму. И спросит по полной программе, если задача не будет выполнена в срок. И тут уж как ни тяни, а надо успевать и укладываться. Конечно, это упрощённая модель, в действительности всё осложняется тем, что по ходу разработки заказчик придумывает новые задачи и сроки и оплата меняются, но не в этом суть.

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

                                                                                                                            4. Хочется ещё раз вернуться к теме работы и оплаты. Мне очень жаль, что я не запомнил, где я слышал и кто сказал очень интересные слова. Смысл был таков: Одного известного человека спросили, сколько он получает и нравится ли ему его работа. Тот ответил, что получает столько, что работа нравится. Был бы признателен, если кто-то напомнит, кто же это был. Так вот. Дело в том, что я отчасти разделяю эту позицию. И совсем не потому, что я такой алчный и меня интересуют только деньги. Но потому, что я не удовлетворил свою потребность в тех аспектах, которые требуют денег. Вспоминаем пирамиду Маслоу. Так вот деньги мне нужны для обеспечения своих естественных физиологических потребностей, чтобы чувствовать себя в безопасности. Возможно, получая больше, я бы больше задумывался над остальным. Но пока я себя не ощущаю достаточно обеспеченным и поэтому работу рассматриваю в плане заработка. И многие на постсоветском пространстве в этой же ситуации. Западнее зарплаты более адекватны и общество совсем другое и с другими потребностями.

                                                                                                                            5. Третья статья будет? Если будет, то от меня совет — пожалуйста, можно ещё менее пафосно и по делу? И очень хочется после слов «Ниже я докажу» увидеть доказательства.
                                                                                                                              –3
                                                                                                                              1. Художник делает это не для себя. Иначе он бы никому не показывал бы свои картины.
                                                                                                                              2. Вы видимо работаете в слишком маленькой компании занимающейся клепанием сайтов на заказ. Я не знаю структуру вашей компании, но думаю в ней все равно можно выделить все три уровня. Но если она совсем небольшая, то ваш непосредственный начальник и является заказчиком. Таким образом описанной здесь проблемы нет. Вообще речь идет о долгосрочных проектах. А не о сайтах-визитках.
                                                                                                                              3. Не в любом случае. И это не связно с отношением к ним.
                                                                                                                              4. то что вы так рассматриваете работу не означает что это хорошо. у меня другое мировозрение.
                                                                                                                              5. хотелось бы что бы вы не просто увидели доказательства, но и постарались их понять.
                                                                                                                                +3
                                                                                                                                1. Художник делает это для себя. Ему доставляет удовольствие сам процесс, мысли о нём. Показывают потом только самое лучшее, чтобы потешить своё самолюбие. А если творчество подвергается критике, то либо очень болезненно на это реагируют, что выливается в оскорбления, либо игнорируют, оправдывая себя тем, что остальные просто не могут понять, насколько крута «картина».

                                                                                                                                2. Мимо. Хотя, это и не очень важно, но если уж Вы затронули эту тему, то стоит ответить, пожалуй. Я работаю в очень крупной международной организации, которая имеет представительства по всему миру. Специализация — крупный outsourcing. Из «местных» клиентов — только крупные гос. предприятия, крупные банки. По миру, из известных — AIG, Canon, Standard & Poor's, Sun Microsystems, T-Mobile, На данный момент в нашем городе штат разработчиков (программисты, менеджеры, тестеры, архитекторы, админы, т.е. все те, кто так или иначе прикладывает свою руку к разработке) около 450 человек. В прошлом году было около 650. Лично я работаю в проекте, который длится с ноября 2007 (активная разработка с января 2008). Я в проекте с самого начала и до сих пор, в данный момент занимаюсь тех. поддержкой, параллельно помогаю в других проектах. С вебом(и сайтами-визитками тем более) никак не связано вообще. Ну да это мелочь. В Вашу теорию не вписывается, а значит моё мнение можно не учитывать.

                                                                                                                                3. Если разработчик не может творчески подойти к решению задачи, то это не разработчик, а кодер. Если разработчик не умеет мыслить логически и не дружит с технической составляющей разработки, то это в лучшем случае аналитик, а скорее «забавный системный архитектор». Хотя, нет… без логики никуда.

                                                                                                                                4. Это не хорошо и не плохо. Зато это объясняет то, что происходит. И это важно понимать. Не надо думать, что человек «таджик», если он думает о деньгах и как их заработать. Может, они ему нужны?

                                                                                                                                5. К сожалению, я не только доказательств не вижу, я ещё и не вижу ответов на вопросы. Вы стараетесь цепляться за фразы, а не отвечать по существу. А как понять доказательства и ответы, которых Вы не даёте — это уже из области фантастики.

                                                                                                                                Кстати, убедившись на живом примере меня, нетрудно сделать вывод, что в людях Вы разбираетесь не самым лучшим образом. Воздержусь от продолжения логической цепочки.
                                                                                                                                  –3
                                                                                                                                  1. Не надо так буквально относится к метафоре, и упрощаете. Я говрю о тех художниках, которые любят демонстрироваться на выставках. Может быть есть и такие кто только для себя работает. Но таких меньшенство, иначе мы бы не видели их картин.
                                                                                                                                  2. только крупные гос. предприятия
                                                                                                                                  гы, видел я их сайты. это не вы берлогу для ЕР делали? )))
                                                                                                                                  На самом деле, ничего не меняется. Вы заинтересованы раздвинуть сроки, как и описано в моей статье. Сами это признаете.
                                                                                                                                  3. Может подойти, может и не подойти. Это смотря как попросите))) Самому ему это не надо.
                                                                                                                                  4. они всем нужны. и мне в том числе. разница в том, что я готов сделать за эти деньги. Одни ничего лишнего делать не будут, потому что им за это не платят. Грубо говря если они видят что-то что можно делать а можно не делать, они не делают. Я же думаю как это поможет проекту. Если поможет я делаю, немотря на то что за это я не получу большую зарплату.
                                                                                                                                  5. доказательства в логике которую я предоставил. я не виноват что вы её не поняли.
                                                                                                                                    +2
                                                                                                                                    1. У меня есть друг — фотограф, знакомая художница и два двоюродных брата — оба художники-дизайнеры. Я имею представление, сколько их работ «мы» не видим. Удалились от изначального пункта 1.
                                                                                                                                    2. Я не знаю, что такое берлога для ЕР. Я вообще сайтами не занимаюсь. В основном, мы занимаемся разработкой систем… Финансовых, банковских, телерадио, и.т.д. Ещё проще говоря — это не сайты. В том смысле, что если эти системы и имеют веб-интерфейс, то сугубо корпоративный. Я не заинтересован двигать сроки. На разработку нашего проекта сроки были поставлены и с нашей стороны соблюдены. Были задержки со стороны заказчика. Просто проект большой, поэтому и долго. Далее мне вообще не имеет смысла суетиться. Поддерживать проект ещё долго, ошибки исправлять надо в отведённые сроки. Где я признавал, что заинтересован что-то двигать?
                                                                                                                                    3. Самому не надо. Для решения задачи — надо. Есть кодеры, которые выполняют чётко поставленные задачи. В основном, это junior developer-ы и простые программисты. Есть разработчики, которые присматривают за молодыми и решают сложные проблемы. Есть лиды, которые решают проблемы на уровне архитектуры и присматривают за всеми остальными. Из вышеописанных не иметь творческого подхода к делу могут лишь junior-ы. Так как остальным надо что-то придумывать. Так или иначе, в том или ином виде.
                                                                                                                                    4. Я тоже стараюсь делать всё, чтобы проект был успешен и все оказались довольны. И зарплату не повышают ежесекундно. Но я работаю на перспективу. Если я поучаствовал в 5 проектах и все они оказались успешны, и я был активен — это даёт право надеяться на повышение в должности и на более тяжёлые задачи и проекты. А это всё даёт… деньги. Ну так вышло… опять эти бумажки…
                                                                                                                                    5. А что есть доказательство? Доказательство — логическая цепочка утверждений, основанная на каких-либо аксиомах и подтверждающая или опровергающая какое-то другое утверждение. Ваши слова — "… рутина это то что нужно заказчику. Ниже я докажу что это ошибка." Не хочется сильно придираться, но само по себе утверждение, которое Вы хотите опровергнуть, как-то уже печалит. Заказчику не важно — рутина у разработчиков или творческий процесс с цыганами и медведями, которые на балалайках играют.

                                                                                                                                    Давайте вернёмся к происхождению терминов «IT-художник» и «IT-таджик», пожалуйста! Можете рассказать, почему именно так, а не иначе?

                                                                                                                                    P.S. Не надо быть таким категоричным. Не все живут в default-city, не все клепают сайты. не все йогурты одинаково полезны…
                                                                                                                                      –3
                                                                                                                                      1. И все они работают в стол)))) А то что им большенство своих работ стыдно показать, то это горит лишь об их профессионализме. Уверен они мечтают показывать все что делают.
                                                                                                                                      2. Кто устанавливает сроки?
                                                                                                                                      3. К решению задачи можно подойти творчески а можно в лоб. Иногда есть только один вариант, тогда он сможет и творчески, а так будет выбирать что проще для него.
                                                                                                                                      4. Все так горят. Я был бы удивлен если бы вы сказали бы иначе.
                                                                                                                                      5. Логика проста. Человеку работающему за бабло выгодно затягивать проект. Если проект укладывается в отведенные сроки, ему нет смысла его делать быстрее. Художнику есть смысл.
                                                                                                                                        +1
                                                                                                                                        1. Чужая душа — потёмки.
                                                                                                                                        2. В самом начале было оговорено, как скоро мы (разработчики) должны отреагировать на полученную заявку о проблеме и в течение какого времени должны решить. Существует несколько уровней проблем — simple, important, urgent, critical. Для каждой есть объяснение. Конечно, можно оспаривать статус, но такое происходит крайне редко. Для critical сроки очень короткие, поверьте.
                                                                                                                                        4. Мы всe тут просто говорим. Однако, я стараюсь говорить правду о том, что есть или то, что думаю или считаю нужным сказать. Мне кажется, что поводов сомневаться в искренности моих слов, я не давал. В подтверждение моих слов просто приведу два факта (чего и от вас хотел бы — фактов). Вчера (в пятницу) я ушёл с работы в 10 вечера, т.к. в последний момент обнаружил пару проблем в билде, который сегодня получит заказчик. Мог бы не заметить, никто бы мне ничего не сказал. Пару недель назад остался на работе до утра, т.к. остался помогать коллеге. Ни об одном из этих событий высшее руководство не знает. Зато знают коллеги, я услышал «спасибо». Цену этого слова я тоже знаю.
                                                                                                                                        5. Нет тут никакой логики. Если проект укладывается в отведённые сроки — это уже хорошо, как минимум. Специально тянуть никто ничего не будет, но есть два момента. Заказчику не отдадут продукт намного раньше сроков. Выполнение задачи занимает всё время, отведённое на эту задачу. Да и потом, редко бывает, что совсем нечего делать. Завершённый раньше срока проект означает освободившийся ресурс. Свободный ресурс всегда полезен руководству компании. Его можно привлечь на помощь, его можно задействовать в новом проекте.
                                                                                                                                          –2
                                                                                                                                          2. Не понял. То есть у вас есть 4 возможных периода времени, на каждый статус? И если задача требует больше времени чем есть, или скажем меньше чем минимальный срок, вы должны назвать строго один из четырех? Но это я так понимаю относится только к багам, а к новым задачам и проетам тоже только 4 возможных ответа? Или все таки вы подходите к этому вопросу более гибко?

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

                                                                                                                                          5. Этого не понял. Почему вы не отдадите продукт раньше срока? Если вы его сделали, так чего ждать?
                                                                                                                                            0
                                                                                                                                            Статусы для багов, конечно. Для нового функционала, новых проектов и.т.п. сроки устанавливает заказчик, на что получает в ответ человекочасы и комментарии и/или корректировки сроков. Если заказчик принимает предложение — всё хорошо. Если нет, то ведутся дальнейшие переговоры.
                                                                                                                                            Насчёт багов — быстро исправленный simple баг отдаётся как можно быстрее. Вообще все баги исправляются по мере сил.

                                                                                                                                            А не отдавать раньше срока — из области психологии и маркетинга. Допустим, заказчик дал на выполнение месяц. Договорились на 300 человекочасов. Все согласны, все довольны. Но тут за полторы недели до срока мы приходим к заказчику и говорим, что всё сделали, можем устанавливать систему. Что должен подумать заказчик? Что реально время для выполнения задачи было слишком велико, за человекочасы переплатили. Тут, конечно, не будет особых проблем с тем, чтобы обоснавать такую скорость, но в следующий раз этот заказчик будет спорить насчёт человекочасов и сроков. Кому это надо? Никому не надо. Слишком короткие сроки — всегда плохо. Есть определённые рамки, за которые выходить нельзя. Это касается как максимума, так и минимума. Невозможно спроектировать и реализовать целую систему за неделю. Даже, если, над этим будет трудиться 100 человек одновременно. Как впрочем и ускорить разработку, сильно увеличив количество программистов.
                                                                                                                                              –3
                                                                                                                                              ну вот что и требовалось доказать. по факту вы, даже несмотря на то, что ваша работа с разными заказчиками, и вы должны держать марку, вы все равно по сути обманываете, не говоря что работа реально обошлась дешевле. Но я в статье писал немного не о таком случае. Я говорю о случае когда заказчик один, то есть это чаще всего владелец компании, и между ним, и программистами есть прослойка в виде менджмента. То есть он по сути не может сменить исполнителя, НЕ УВОЛИВ ВЕСЬ ШТАТ. Если вы умудряетесь даже в вашей ситуации обмануть заказчика, когда он может в любой момент отказаться от ваших услуг, представьте что происходит когда заказчик гораздо сильнее привязан к исполнителю? Наглось вообще не знает границ.
                                                                                                                                                +1
                                                                                                                                                А в том и дело, что чаще всего расходуется примерно столько человекочасов, сколько было заявлено и сроки — реальный ориентир. А если что-то получается сделать быстрее — это не всегда обман. Это может быть из-за привлечения немного большего количество разработчиков (т.е. такое же количество человекочасов, но в более сжатые сроки). Делается для небольшой подстраховки, чтобы в любом случае успеть в срок. А вообще, знаете, не все заказчики глупы. Поверьте, американцы умеют считать деньги. Да и европейцы тоже. Да и именем и репутацией наша компания дорожит. В данном случае это дороже, чем обмануть заказчика 100к $.