Пользователь
0,0
рейтинг
21 июля 2013 в 14:58

Управление → Жизнь управленца, кадр 1, не надейтесь на понимание из песочницы

95% своей сознательной жизни я связан с ИТ, начав как переводчик, достаточно быстро перешел в ИТ, развитие проектов, в общем кто плавал, тот поймет.

Основная проблема, с которой я столкнулся, во время своего путешествия, это конечно люди. Не плохие люди и не хорошие, а просто люди-сотрудники.

Так вот, в любой нормальной ИТ компании, которая занимается программерством, 90% это программисты процентов, 7% технари, остальное административный отдел. Самые простые люди в компании это конечно администраторы, в прямом смысле этого слова, те люди которые делают чай, кофе, чистоту, учет и безопасность. И так часто происходит, что именно эти люди самые бесправные, вы знаете, что их легко заменить, их никто не замечает и тд и тп.


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

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

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

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

Так вот, вначале определите таких «теорестов». Затем, поймите что это действительно они, т.е. сделайте скрининг, «теорест» должен отвечать следующим требованиям:

1) Верит в стандарты, великие книги, авторитеты
2) Постоянно их цитируют
3) Считает, что ему уже программировать не «айс», у него настало время «коучинга», «персонел девелопмента», «визуалайзина», «стратеджик мэппинга» и тд.

Определили? Посчитайте сколько вы на них тратите, если бюджет на «теорестов» превышает 5% от общего фонда ЗП, всегда есть отличный способ с ними справиться.

Увольняйте. Запомните, никогда не надейтесь на них, что вот мол они такие умные, когда настанут проблемы в проекте они вас вытащат. Не думайте, что они умнее вас, если вам нужен совет, избегайте «теорестов», и найдите практикующих менеджеров. Запомните отличные программисты = хреновые менеджеры. Из собственного опыта могу сказать что они уйдут в самый неподходящий момент потому что:

1) Когда вы заботитесь о клиенте, вы нарушили целых 5 пунктов из стандарта ITIL, и теперь ваш выстраданный SLA может быть нарушен, и это ужасно…
2) Потому что в другом месте его понимают, и любят и ждут
3) Ему заплатили на 100 долларов больше.

Причин масса. Увольняйте «теорестов», сразу и жестко. Очень быстро, без долгих объяснений. А потом оглянитесь вокруг, наверняка в компании много людей, которые тупо пашут, в то время как толпа народу каждые два часа обсуждают «паттерны использования методик гибкого программирования к подходам решения задач» когда проект на грани сдачи. Поищите тихих, вдумчивых людей, которые пишут код, находят решения и внедряют их. Посмотрите кто больше всех комитит в СВН, и кто приходит утром а уходит вечером. Найдите тех, кто вам постоянно не полощет мозги по поводу ЗП и тогда.

1) Сделайте их начальниками
2) Дайте им хорошую ЗП

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

Единственный «теорест», кто допустим в компании это методолог, который должен:

1) Отвечать за поддержание внутренних процессов
2) Делать документацию
3) Отслеживать тренды.

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

Продолжение:
Жизнь управленца, кадр 2, жесткая воля
Жизнь управленца, кадр 3, коммуникации
Жизнь управленца, кадр 4, Планирование — Постановка задачи
Павел Пронин @undry
карма
0,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

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

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

  • +15
    На мой взгляд очень спорно.
    Всё верно, если речь идёт о проекте на продажу: сайте, промо страничке, может даже портала…
    А вы попробуйте с теми кто «тупо пашет» сделать хороший стартап. Я уверяю Вас — всё загнётся, ибо у них даже не будет желания делать не по ТЗ, ах да на стартапе то с ТЗ обычно худо. Т.е. что получаем нет ТЗ => не надо работать(«тупо пахать»).

    Думаете зря товарищи из Google и Ya ищут не просто кодеров, а всесторонне развитых людей которые порой «каждые два часа обсуждают «паттерны использования методик гибкого программирования к подходам решения задач»»

    А по поводу подхода «клиент всегда» прав, есть компании, которые порой отказываются работать с клиентом из-за «треугольных кнопок», дабы сохранить свою репутацию профессионалов!
  • –2
    Вы не совсем меня поняли. По поводу «тупо пашет» я говорю про тимлидов, их конечно нужно воспитывать, об этом я расскажу позднее. Я говорю о том, что во многих командах, роль неформальных лидеров, которые в будущем стараются стать формальными лидерами, играют не те игроки, которые нужны команде. Я воспитывал лучших тимлидов именно из «пахарей» и они показывали лучшие результаты.

    ТЗ это не панацея, у нас поставлен процесс использования Итерации+Жира+Конфлюенс+Внутренние стандарты. Этого хватает чтобы актуализировать все задачи. Пробовал делать хорошие стартапы, делал. Те кто «тупо пашет», не значит что пашут тупо. Они просто тратят свое время эффективно.

    Всесторонне развитые люди (ВРЛ), как вы их обозначали это зло для компании среднего размера. Завтра этот ВРЛ свалит в тот же яндекс или гугл в момент скажем сдачи проекта, и что вы будете делать? Упирать на его лояльность? У ВРЛ ее чаще всего нет.

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

    Мы фиксируем все желания клиентов в Жире, и так избегаем многих проблем «шапозакидательной» молодежи, которая считает себя «быстрее, выше и сильнее» клиента.
    • +1
      я говорю про тимлидов, их конечно нужно воспитывать
      Я воспитывал лучших тимлидов именно из «пахарей»
      И когда клиент пришел к нам, и готов платить ожидаемые деньги, я априори считаю что он, лучше разбирается скажем в металлопрокате чем мы, и когда он говорит что ему нужны зеленые буквы на черном фоне, мой дизайнер будет плакаться, а мой продажник, скажет «подскажите почему, может стоит вот так»

      С каких пор «менеджеры» сайтоклепальщиков стали гуру в управлении проектами?
      Есть две винрарные книжки Мифический человеко-месяц Брукса, и Человеческий фактор Де Марко, для тех кто хочет управлять командой разработчиков — мастхев. Для мелких фирм которые живут потоком заказов на сайты-визитки, такой совковый подход к работе вполне имеет право на жизнь, но когда перед программистами ставятся задачи посложнее чем сохранить в бд данные из веб-формы, тут уже в дело вступает совершенно другой подход.
      • +2
        А как же «Deadline. Роман об управлении проектами», того же Де Марко?
        По-моему куда легче и интереснее читается, чем «Человеческий фактор», ну это так, имхо. =)
        • 0
          Ну у Де Марко почти все книги легко читаются. Человеческий фактор, роман об управлении проектами, вальсируя с медведями — все книги зачетные. Но я бы выделил человеческий фактор, там больше практических советов и исследований на тему мотивации демотивации, тимбилдинг и проч.
          • –4
            А с каких пор вы так легко определяете людей в сайтоклепальщики. Следите за тоном. Ведите себя профессионально. Те проекты, что я делал, вы вряд ли делали.
            • +2
              Сайтоклепальщики — это люди которые клепают сайты для металлургов, и которые красят кнопки в различные цвета лишь бы клиенту понравилось.
              Ну а проектами мне с вами мерится не с руки, разная специфика, разные подходы.
      • 0
        Автор пишет
        1) Верит в стандарты, великие книги, авторитеты
        , вы оспариваете его статью, упоминая книги и авторитета.
  • +6
    По моему «теорест» находится не на своем месте. Это уже не просто программер.
    • –6
      Согласен. Но скажем для моей компании в 30-40 человек, тратить горючее на «теореста» это слишком, если это больше 5%. Здесь важно отличать архитектора скажем, который с головой ушел именно в практику программирования от человека который ушел в теорию.

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

      1) Стажер
      2) Джуниор
      3) Мид
      4) Сениор
      5) Архитектор

      Для того, кто больше себя видит в управлении это:

      1) Стажер
      2) Тестер
      3) Старший тестер
      4) Тимлид
      5) Менеджер портфеля

      Остальное, это исключения, которые нужны, но очень дозировано.
      • +4
        То есть вы считаете, что развитие Стажер -> Джуниор -> Мид -> Тимлид-Сениор -> Руководитель априори провальный?
        Тогда мне придается вас разочаровать.

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

        Не зря раньше, когда крупный капиталист передавал свой бизнес наследнику — наследник должен был проработать на всех уровнях ключевых должностей в компании.
  • +9
    Посмотрите кто больше всех комитит в СВН

    Коммит коммиту рознь. Хорошей практикой считается делать атомарные коммиты. Так вот, какой-нибудь джуниор может сделать в день 10 коммитов, фиксающих 10 простых багов (каждый из которых сродни смене константы, перенести что-то на блок кода выше и т.д.). А «теорест» может сделать 1 коммит, который капитально перелапачивает систему и избавляет от проблем в дальнейшем.

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

    Как по мне, так вы просто попали не на тех «теорестов», раз всех под одну гребенку сводите и презираете их.
    • –4
      Насчет коммитов согласен, но, нужно же понимать что нужно смотреть на что коммитят.

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

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

      1) Тимлид — 1
      2) Программисты — 5
      3) Тестеры — 2

      На 3-4 здоровые команды более чем достаточно одного методолога, которого можно воспитать из теореста, а можно гораздо лучше вытащить из тестеров и сделать отличным аналитиком. Я не люблю теорестов, я против слепого следования стандартам. Я за тех людей, кто работает, может быть не умеет много говорить, но умеет много делать. И задача менеджера таких людей находить и не смотреть на внешний лоск, а искать внутренний стержень.
      • +5
        Методолога из тестеров?

        Без практики нельзя понять, когда нужен Singleton, а когда Dependency Injection.
        А на уровнях выше — когда делаем отчёты по OLTP базе, а когда уже нужен OLAP, и какую использовать структуру данных, чтобы любой отчёт быстро построился в дальнейшем.
        • –5
          У нас разные понятие методолога. Методолог следит за внутренними процедурами и стандартами. А решения по архитектурному строению БД принимает архитектор проекта, при этом их может быть несколько. Тогда по Дельфийской методике.

          Методолог не должен принимать архитектурные решения. Их должен принимать 100% практик, кто варится в теме постоянно.
          • +3
            Тогда я не понимаю суть «внутренних стандартов», и зачем на это выделять человека.

            Кодинг-стайл, фреймворки, инструменты — это не то.
            Тогда что то? Сколько раз в день пить чай и стоять на скрам стенд-апе или сидеть?
            • –5
              Это плохо, что вы этого не понимаете. Это формат постановки задачи, как оценивать задачи, эталонные оценки, процесс выяснения всех требований, составление итераций, беклогов, приоритизация задач и многое, многое другое.
    • +7
      Не надо делать кучу изменений одним коммитом. Надо заводить ветку, а потом мержить, тогда выстраивается вменяемая и понятная история изменений, по которой можно понять, когда и по какой причине исправлялся код. Ну а ещё автору статьи рекомендуется отправить SVN на свалку, и взять Git или Mercurial.
      • –4
        Не надо делать кучу изменений одним коммитом.

        Покажите пальцем на того, кто говорит о куче изменений и одном коммите?

        Надо заводить ветку, а потом мержить,

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

        Ну а ещё автору статьи рекомендуется отправить SVN на свалку, и взять Git или Mercurial.

        Если бы в этом мире было бы все так просто, полагаю, не было бы и этого поста.
        • +2
          Покажите пальцем на того, кто говорит о куче изменений и одном коммите?
          Показываю: Вы.
          А «теорест» может сделать 1 коммит, который капитально перелапачивает систему и избавляет от проблем в дальнейшем.

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

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

          После ребейса история будет такой же
          Тут цикл статей был обстоятельно объясняющий, почему плоская история — это плохо, излагать из сейчас нет никакого желания, скажу лишь то, что каждый раз когда вы ребейзите ветку с несколькими коммитами, Б-г убивает котёнка. Для подробностей воспользуйтесь поиском по хабру.
          • –1
            Показываю: Вы.

            Да ну, и где же? Или Вы не различаете понятия атомарности коммита и одного большого коммита?

            Это значит, что система не справляется со своими задачами и нуждается в замене.

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

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

            Да какая разница? Цель моего комментария показать, что заводить отдельные ветки для коммита — не всегда нужно. Вы ведь это утвержали в своем комментарии выше.

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

            А я видел цикл статей показывающих, что плоская история лучше разветвленной. И что? Сам я сторонник мержей, но Вы в своем предыдущем коммите указали ветвления и мержи как единственно правильный способ разработки. А это как-то непрофессионально.
            • –1
              не различаете понятия атомарности коммита и одного большого коммита
              А «теорест» может сделать 1 коммит, который капитально перелапачивает систему и избавляет от проблем в дальнейшем.
              Это называется «один большой коммит».
              и нельзя просто так взять и сменить систему контроля версий
              Отмазка для оправдания своей лени и некомпетентности. Времязатраты на переход на Git очень быстро окупаются.
              что заводить отдельные ветки для коммита — не всегда нужно
              Ветка заводится не для «коммита», а для «фичи». Если «фича» добавляется одним коммитом, который можно вот прямо сейчас протестировать, провести ривью и залить, и т. п. — ветку можно и не заводить.
              как единственно правильный способ разработки
              Тут дело даже не в правильности. Это единственно возможный способ потом понять понять, что вообще происходило, и в каком состоянии находился код в момент данного конкретного изменения. Это единственный возможный способ гарантированно находить приводящий к регрессии коммит, т. к. при «выпрямлении» истории теряется необходимая информация о контексте.
      • –4
        Я не люблю такой подход. SVN вполне подходит под все наши задачи. А постоянно менять что-то в гонке за новизной, не всегда считаю это хорошо. Есть еще проекты на зенде, кто то фанат ыии. Вопрос в эффективности решения и стоимости его замены.
  • +4
    То, о чем вы пишете, больше подходит компаниям которые работают над потоком разных проектов. И в этой конкретной области, с учетом размера компании и прочего — вы, я думаю, правы.
    Но сравнивать с Google, Facebook и.т.д. бессмысленно. Эти компании продуктовые и работают над «одним» проектом. В таких компаниях ориентир на одного хорошо платящего заказчика чаще всего губителен в long term. А вовремя посланный клиент, может спасти от потери десятка. И в таких компаниях держать определенное количество «теорестов» — единственный шанс не попасть в технологическую проблему.
    • 0
      Вы абсолютно правы. На 100%, я говорю именно о тех, компаниях, которые работают над потоком проектов.
  • +4
    Стандарт — это «по умолчанию» правильно, отклонения должны быть обоснованы. В тексте вы привели хорошие причины отойти от стандарта, но это совершенно не повод класть на него постоянно, изобретая велосипед.
  • +5
    какой-то мифический персонаж, получается, вам нужен. человек развивался ровно до тех пор, пока работодателю это выгодно, а потом раз — и перестал расти и требовать больше денег. я таких не встречал. либо человек развивается, либо нет. и сам бы не хотел оказаться в такой ситуации, когда все мои знания нужны только на этой работе, а случись искать другую — будешь ее искать либо в на 100% аналогичной компании, либо идти на меньшие деньги.
    • –4
      Мне нужен абсолютно обычный человек. Тот кто считает стандарт маяком, а путь прокладывает сам. Я сам изучил все стандарты, скоро стану PMP, но до сих пор считаю что обследование+работа головой+хорошая стратегия, делают проект успешным, а не фанатичное следование теориям.
      • +1
        > Я сам изучил все стандарты,
        Вам надо на следующий уровень — «теперь я сам пишу стандарты»
        • –2
          У нас в компании есть хендбук, который состоит из стандартов, которые писала наша команда, вы правы. Стандарты я уже писал в паре бизнес ассоциаций, работа не приятная и нудная. Важнее читать стандарты, брать оттуда лучшее и применять на практике.
  • +14
    Запомните отличные программисты = хреновые менеджеры.
    Посмотрите кто больше всех комитит в СВН, и кто приходит утром а уходит вечером. Сделайте их начальником.


    Я вижу в этих утверждениях противоречие. Поясните, пожалуйста :).
    • –4
      Да согласен что я тут неправильно составил фразу. Отличные программисты = плохие менеджеры, которые должны общаться с клиентом, учитывать его требования и вести переговоры, но хорошие тимлиды.

      А вот те кто начинал тестером, отрабатывал с заказчиком проекты, те вырастают в отличных менеджеров, которые готовы вести проект.
      • +8
        Способности к программированию никак не коррелируют со способностями руководить. Можно очень сильно промахнуться.
      • +1
        Отличные программисты = плохие менеджеры, которые должны общаться с клиентом, учитывать его требования и вести переговоры, но хорошие тимлиды.


        Я правильно вас понимаю, что по вашему мнению тимлиду не нужно общаться с менеджером проекта, учитывать его требования, вести переговоры? Как вы считаете, тимлид — это руководящая должность или «просто выделенный программист, который представляет команду — чтобы менеджеру было удобно с ними общаться»? Мне довелось работать и в должности тим лида, и в должности менеджера проекта — есть некие сомнения в ваших выкладках.
        • –1
          Немного не так. Тимлид это руководящая должность, это человек который общается с клиентом, руководит командой. Но, все организационные вопросы, координационные, денежные решает менеджер проекта. Рассмотрим ситуацию, Тимлиду нужно пояснить задачу, нужна информация от клиента, вместо того чтобы гонять человека который развивает проект, мы передаем запрос на поиск конкретного лица, которое может дать пояснение менеджеру проекта. Это происходит тогда, когда основной контакт Заказчика, не может дать пояснения.

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

          Менеджер проектов ведет несколько проектов, тимлид всегда только один.
  • +9
    Видимо наш предыдущий менеджер также думал. В итоге имеем более 60 проектов говнокода. Зато нанимали «трудолюбивых» программистов, а не тех, кто что-то слышал про стандарты, например.
    • –4
      Тут важно не впадать в крайности. Говнокод != несоблюдение стандартов. Я думаю вы не совсем поняли пост. Я говорю о том, что каждая компания, должна основываясь на стандартах, делать свои внутренние, практичные, применимые к данной конкретной компании процедуры. Говнокод зло, но и скажем избыточные комментарии тоже зло. Все должно быть в меру.
      • +5
        Я из вашей статьи увидел, что управленцам нужны трудолюбивые рабы, а не думающие личности. Они сразу становятся неудобными и их надо увольнять.
        Мне лично кажется, что тут вопрос действительно лояльности и личного авторитета. Если их нет, то да, только рабы.
        • +8
          Автор боится, что его подсидят. Вот и весь вопрос.
  • 0
    По-моему автор прав во всем. Другое дело, что он не договорил, что ситуация применима только к краткосрочным и небольшим проектам. Огромный пласт проектов требует не «сделать хорошо», но «сделать быстро». А грамотная разработка скорости не прибавляет. В общем для многих веб-студий специалисты высоких материй просто экономически не выгодны, да и самим этим специалистам там делать нечего — интересных задач для них не будет.
  • +9
    Прочитал. Возник вопрос: «Кто ты ваще такой?». Каких лучших тимлидов ты «выращивал»? Имя, сестра, имя!
    • –6
      Ну в будущем я обязательно объясню в статьях кто я такой. На данный момент запускал пять или шесть компаний, все выводил в ТОП-20 ИТ компаний в двух разных странах. Одна была №1. Потом я компании либо продавал, либо вливал в большие холдинги, которые долгое время были моими клиентами, а потом покупали команду и компанию. Затем я доводил продукт до логического конца, и да, это были большие, республиканские продукты. После этого я уходил из компании, когда задач становилось мало, и открывал что-то новое. Сейчас веду где-то 7-й стартап.

      Из 7-ми стартапов провальным был только один, связанный с интернетом. Остальные, b2b компании все были очень успешны.
  • +6
    Программисту и должно быть насрать на клиента. Это неотъемлимая и наиболее приятная часть профессии. Существует негласное, но очевидное разделение: управленцам насрать на код, программистам насрать на клиента. При таком балансе каждый может заниматься своим и только своим делом и преуспевать в нем.

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

  • +5
    Я не программист, поэтому скажу со своей колокольни. У нас отрасль простая — изыскания, строительство. Так вот задача «тим лида» (руководителя проекта) донести до клиента опасности уходов от стандартов.

    Надо прежде всего понимать, что любой стандарт — это как ТБ, если есть правило, значит, родилось оно не на пустом месте. Желание изобрести велосипед возникает там, где не хватает знаний этих стандартов.

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

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

    Было бы интересно послушать вашего сотрудника-подчиненного, работающего с клиентом во главе угла. Может, Вам повезло с Заказчиками, но если я буду на 100% потакать их желаниям — то мои подчиненные будут работать по 20 часов в день без выходных, по 3-4 раза переделывая одно и то же.
  • 0
    Так зарожадлся Совковый Аджайл.

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