Vic

  • Публикации

    2 513
  • Сообщений в день

    0,54
  • Зарегистрирован

  • Посещение

О Vic

  • День рождения 01.01.1979

Дополнительная информация

  • Имя
    Victor
  • Адрес
    Санкт-Петербург
  • Род деятельности
    программист
  • Интересы
    велик, спелео, потрепаться...
  1. Точно! Нужен тимлид в команду разработки ядра линукс. Команда 4 человека, денег 120 плюс - минус. Стучаться в личку.
  2. Ситуация в том, что для выполнения задачи к сроку нужно работать 8 часов в день. Если человек не может работать с той же отдачей, что показывал на собеседовании, целый день и целую неделю, а команда, которая его нанимает этого не знает и рассчитывает на него как на полноценного участника - это проблема. добавлено 4 минуты спустя Загнать всю коммуникацию в медленные формальные каналы связи, такие как JIRA, почта и т.п. - убить эффективность. В случае необходимости координировать деятельность нескольких функциональных команд для создания общего продукта отказаться от формальных каналов связи у мне не видится возможным. Я тупо не понимаю - как. Научите?
  3. Вообще сишные компиляторы так и собираются: чем под руку попадётся собирается версия себя любимого, но со "префиксом", а потом этой свежесобранной префиксной версией из тех же исходников собирается уже боевой.
  4. Всё так. Другое дело, что когда идёт работа "на результат" в scrum-команде, не существует ситуации, когда один из участников работает 1 час в день тогда как остальные 8. Такая ситуация возможна когда начальник сам разаёт подчинённым задачи и сам ставит сроки. Эффективно? Нет. Но так, почему-то, многие привыкли. Причём и со стороны начальников, и со стороны подчинённых.
  5. То есть у вас, типа, "сильная матрица". Будь я разработчиком в такой ситуации, я бы при получении задачи от PM1 вида "бросай текущие работы, работай над моим проектом" просто брал бы его за руку и вёл бы к PM'у проекта, над которым ты сейчас работаешь со словами "смотри, чувак велит мне перестать работать над твоим проектом" и наслаждался бы зрелищем. К матрицам обычно есть "исполнительный Project Management Office", в который собраны все PM'ы, и который, в том числе, занимается расстановкой приоритетов между проектами. Погоди, не понял. Кто руководит проектами? В смысле, кто отвечает за то, чтобы работа была сделана в срок и бюджет? Продаваны? Матрица с функциональными командами из 1-го человека. Бывает и такое. Матрицей управлять сложнее всего - она компромисс между функциональной и проектной схемами. У функциональной огромный минус в том, что у PM'а нет практически никакой власти => проект делается непредсказуемо. У проектной другая проблема - нужно постоянно нанимать / увольнять людей под проекты. Матрица, типа, балансирует эти недостатки, но проекты постоянно дерутся друг с другом за ресурсы, и это надо разруливать. Не понял метафоры. План рушится при изменении сроков работы на критическом пути? Так это так и должно быть. В этом случае проект действительно летит к чёрту. Или вы не смогли разобраться, как в Project отслеживать прогресс работ? Это действительно нетривиально. Судя по всему, в вашей организации agile в чистом виде не подойдёт - вы жёстко завязаны на сроки. Не знаю, не искал. Я пытался сдавать экзамен на русском, понял, что я не понимаю вопросов, потому что не понимаю терминологии и сдавал на том, на котором учился. Так и узнавать. Когда сконфигурирована производственная линия под ваш заказ. Когда она запущена. Сколько экземпляров произведено за первую неделю. Сколько за неделю N. Когда закончена вся партия. Когда она упакована. Когда отправлена. Когда прибыла на таможню. Когда покинула таможню. Когда приехала к вам. Я, честно говоря, не в теме, как работает производство железа, поэтому могу какие-то стадии упустить. Ну и да, потери от срыва сроков надо на уровне контракта разделить с поставщиком. Стратегия называется "transfer risks". Если в контракте не написано, когда и что должен сообщить поставщик, он никогда этого сообщать не будет. Ему это не надо. Надо или самим интересоваться, или в контракте прописывать. "Fire and forget" только ракеты бывают, к подрядам и субподрядам такой подход применять наивно. Вот это правильно и логично. Верстаеть планы из реальных сроков. Это очень серьёзная ошибка - сроки, которые кажутся затянутыми просто взять и сократить. А потом удивляться, как так, срок сократили, а работа всё равно делается столько, во сколько её оценил исполнитель и даже чуть дольше. А это от того, что у проекта есть только один срок - срок сдачи. Хотя промежуточные сроки (milestones) ничуть не менее важны и за их выполнение / невыполнение должно быть то же самое поощрение / пенальтизация. Если продолбаны все milestones, нет варианта при котором срок сдачи всего проекта не будет также продолбан. Инфа сто процентов (ц). Очень разумно. Но, как я понимаю, в вашей текущей ситуации, чтобы этот подход заработал, придётся потратиться на организацию проектного управления. Одного желания "чтобы всё работало как надо" недостаточно, чтобы оно заработало как надо. добавлено 4 минуты спустя Если ты за следующие 9 часов выполнил по задаче, на которыю Вася тратит по 10 часов, то и получил в 10 раз больше Васи. Если ты потратил эти 9 часов на разглядывание котиков - то получил столько же, сколько Вася. Если при этом рядом сидит Петя, который такие задачи решает каждую за 5 часов, то не надо расстраиваться, если вас обоих этим Петей заменят.
  6. В прошлый раз мы рассматривали случай, когда задача настолько большая, что её нельзя точно оценить. В этом случае для получения более точных оценок задачу надо декомпозировать. То, что декомпозированные задачи далеко не все параллелятся - это другой вопрос, и решается он методом создания "Network Diagram" На написании "плана" работа манагера не заканчивается, ваш К.О. Нужно ещё сделать так, чтобы окружающая реальность этому плану соответсвовала. И чем позже будет найдено расхождение реальности с планом, тем меньше времени останется на исправление ситуации. Поэтому проверять реальность надо раз в D дней. Конкретное значение D - зависит от. Я в конторах 10-100 резработчиках обычно видел еженедельные синхро-митинги между всеми руководителями направлений. Вот для этого и приходится скрещивать ежа с ужом: SCRUM, для работы с невыясненными требованиями, и Waterfal, потому что бизнесу нужны хоть какие-то оценки по срокам. Говорят, в PRINCE2 "они как-то эти проблемы решают", но я его ниасилил и в наших широтах не видел ни одной организации, которая бы работала по этой методологии. Про SCRUM - scrum.org. Про Waterfall - PMBoK, точнее даже книжку Rita Mulcahy про подготовку к сдаче экзамена на PMP. Сам экзамен можно не сдавать, но книжка мозги на место очень хорошо ставит. Ты прямо книжные примеры приводишь Это называется Procurement Management, при планировании водопадом на это тоже пишется план и назначаются контрольные точки. Чтобы о том, что подрядчик продолбал сроки ты узнал не в момент, когда должен был бы получить что-то от этого подрядчика, и когда сделать уже ничего нельзя, а раньше, чтобы у тебя был хоть какой-то осознанный манёвр. Понимаешь, если исполнитель даёт сроки без запаса на котиков, но в процессе работы будет на котиков отвлекаться, то в итоге не выдержит сроков и твои планы разрушатся. Если бы у тебя изначально был бы срок, учитывающий котиков и необходимость автору делать ежедневно домашку по арифметике и русскому, сроки были бы больше, но ты бы про это знал с самого начала. При планировании нужен не "наиболее оптимистичный срок", а наиболее реалистичный. А в зависимости от длительности этих сроков ты или нанимаешь конкретный "ресурс" за конкретные деньги, или ищешь другой ресурс, который за бОльшие деньги, но меньший срок сделает ту же работу. Очень от работодателя зависит.
  7. Обычно срок называют для задачи. От того, когда эту задачу начнут делать, срок её исполнения не поменяется. Из этого правила могут быть исключения вида "пять релизов назад мы оценивали эту фичу в N, сейчас архитектура поменялась до неузнаваимости, новая цена этой фичи M". И это совершенно правильно. Из двух вышесказанных пунктов следует, что если нужно оценить задачу масштабом в 2-3 месяца, её надо декомпозировать на куски по 2-3-5 (не более 5-ти!) дней, оценить и из суммы оценок сложить оценку большой задачи. А вот это в SCRUM измеряют Focus Factor'ом: отношением календарного времени, которое требуется на решение задачи, к трудоёмкости этой задачи оцененной в человеко-днях. Задача была на 2 человеко-дня, но сделать её удалось только за всю рабочую неделю, потому что отвлекали всяким (поддержкой, багофиксом, тимбилдингами бесконечными), значит FF получился 2 / 5 = 0.4 Из этого вывод: чтобы получить правдивый каленадрный срок, все оценки данной команды надо разделить на 0.4. Невыполнение срока это "так себе риск" в том смысле, что он есть всегда и стратегия минимизации вероятности его наступления одна: нужно раз в D дней проверять, все ли задачи, запланированные к исполнению на этот день выполнены. Если не выполнены, то понять почему и устранить этот фактор. Если фактор неустраним - пересчитать прогнозы с учётом вновь открытого фактора. Только этим обычно никто не парится, предпочитают с мешающими факторами бороться просто - давить на исполнителей. Работает "так себе": сроки, конечно, сокращаются, но не за счёт устранения мешающий факторов, а за счёт уменьшения качества.
  8. Ты, что ли, в матричной структуре сидишь? Когда каждый разработчик подчиняется разным PM'ам из разных проектов?
  9. Это решит команда. Если ей будет нужен тимбилдинг - она его организует и проведёт. Обратное не работает: если взять пачку интравертов-программистов, провести "тимбилдинг", и не делать ничего больше - самоорганизующейся команды не получится. добавлено 1 минуту спустя Поддержка это поддержка, а тут разговор шёл про необходимость софт-скилов программистам, которые кроме как с себе подобными не общаются. И тем более они не общаются с клиентами. Так-то ты всё правильно говоришь.
  10. Программисты, обладающие софт-скилами, могут формировать самодостаточные одноранговые команды, для описания работы которых есть методология SCRUM. Программисты, не обладающие софт-скилами не могут формировать одноранговых команд, им нужен выделенный человек с властью - тимлид.
  11. Опять же сильно зависит от траектории. Одно дело по касательной тут, гореть будет дольше; другое дело по направлению в центр - по поверхности шарахнет только в путь. С низкой орбиты в центр попасть сложно, а вот с высокой надо совсем чуть-чуть ∆V
  12. У современных операторов замена симки бесплатная операция. На современные влезает додура всего PS: с удивлением узнал, что на проце симки (!) выполняется код, в котором бывают дыры.
  13. многопоточность и atomic... volatile... Только не надо говорить, что для "Hello world!" проблемы многопоточности и синхронизации кэшей процессоров не существуют.
  14. Нет под Linux. Так-то меня и обычный устраивает, но Linux...
  15. Клевая тема, присоединюсь к вопросу об альтернативах. Но мне нужно странное - мне нужны групповые звонки хотя бы в режиме аудио. Видео (или рассматривание общего экрана) - вообще мечта. Про всякий GoToMeeting знаю, но хочу чего-то легковесного, что было бы и на телефоне, и на десктопе, и на десктопе с не-винндой.