_AB>То есть, пригласили тебя как кризис-менеджера разрулить ситуацию. Ты посмотрел и говоришь,
Меня не приглашали в ту конкретную компанию разруливать ту конкретную ситуацию. Я прочитал тред здесь, на RSDN, и дал оценку ситуации. Как и просил enji: e> А вы чего думаете?
Меня не спрашивали, что должен сделать новый кризис-менеджер. В стартовом сообщении вообще нет ничего ни про кризис-менеджера, ни про то, что где-то кого-то уволили. Вычитывать это между строк и где-то в комментах какого-то блога у меня нет ни интереса, ни желания.
Если бы вопрос был сформулирован, например, так:
"Меня пригласили кризис-менеджером и попросили разрулить ситуацию, с чего мне начать?" — я бы дал иные рекомендации.
В первую очередь, если это возможно, дал бы рекомендацию не связываться: ситуация, скорее всего, довольно гнилая, и как ее ни разруливай, все равно останутся недовольные. Здесь нет выхода win-win для всех. Кто-то обязательно что-то потеряет, а это, в свою очередь, ударит и по менеджеру, пусть даже косвенно.
А дальше — зависит от того, насколько все это критично, сколько ресурсов на это потрачено, сколько еще можно потратить. Возможно, дешевле будет "с нуля" начать повторный процесс со сторонними поставщиками, задействовав другого эксперта-приёмщика (программиста ли, тестера ли, или самому с лопатой). Если там что-то сложное, придется искать root cause — с чего всё начиналось. Разбираться в ситуации. Искать мотивы, почему что-то, что могли сделать in house, было вынесено сторонним поставщикам. Без понимания ситуации ничего не выйдет. Может, там изначально предполагалась "отмывочная" схема с откатами, а своими этими разборками вида "не пущу компонент сквозь ревью" программист только мешает.
_AB>Основная проблема с этим программером, что он рогом уперся и не хочет работать с подрядчиком, а хочет сам писать всё с нуля.
На этом месте неплохо бы выслушать аргументы программиста. То бишь, понять, почему он так поступает. Что им движет.
Свалить вину на того, кто не может ответить — классический ход форумных дискуссий. В менеджменте тоже применяется, если надо "шарить респонсибилити" (С). Но если надо дело сделать — надо слушать все стороны.
Здравствуйте, SkyDance, Вы писали:
SD>В первую очередь, если это возможно, дал бы рекомендацию не связываться: ситуация, скорее всего, довольно гнилая, и как ее ни разруливай, все равно останутся недовольные. Здесь нет выхода win-win для всех. Кто-то обязательно что-то потеряет, а это, в свою очередь, ударит и по менеджеру, пусть даже косвенно.
Здравствуйте, SkyDance, Вы писали:
SD> В менеджменте тоже применяется, если надо "шарить респонсибилити" (С). Но если надо дело сделать — надо слушать все стороны.
Судя по спелингу это камень в мой огород. Но в моем сообщении я имел виду что вышестоящее руководство должно принимать участие в принятие решения по будущему проекта. Менеджер не имеет полной авторити для решение судьбы данного проекта unless опять же вышестоящий менеджмент выдал "индульгенцию/авторити" данному кризис-менеджеру.
Я читал что там в живом журнале выложено. Выглядит все так, что программист закусил "губу" решив что он самый умный. Тем самым поставил проект под угрозу срыва и на уговоры не соглашается. Это уже попадает по понятие саботаж и отсутствие командной игры.
Здравствуйте, enji, Вы писали:
E>Я же сам готов всё сделать. Это будет бесплатно и гораздо лучше, чем сделает подрядчик. E>Нужно немедленно разорвать контракт с подрядчиком. E>Тогда я (программист) берусь все сделать через месяц и совершенно бесплатно ( за зарплату), только ко мне никто не должен лезть и мешать.
Сильно важна история. Если подрядчик работает давно и имеет кучу успешных проектов, то программиста надо пинать. В любом случае, локальные программисты обычно важнее сторонних подрядчиков.
E>- Интересы предприятия определяет Директор. Это правильный путь. Если Директор определил, что надо работать с подрядчиком, то надо либо подчиниться, либо увольняться. Недопустимо и неправильно молча делать вид, что подчиняешься приказу, но на самом деле пытаться угробить работу подрядчика и продвинуть свою.
В этот момент очень многие исполнители:
1) Уволятся.
2) Начнут работать по принципу: "Ну раз Директор (с Большой Буквы) такой умный, то и делать всё будем как он скажет". Обычно это заканчивается плачевно через некоторое время, так как без инициативы со стороны исполнителей проекты часто загибаются.
E>- Интересы предприятия в том, чтобы эффективно, качественно сделать проект. Директор просто ошибается, нужно ему доказать, что он не прав и убедить изменить решение.
Тут неизвестно что нужно сделать: сдать проект и забыть или дальше с ним работать.
Здравствуйте, SkyDance, Вы писали:
K>>Я читал что там в живом журнале выложено. Выглядит все так, что программист закусил "губу" решив что он самый умный.
SD>Сам программист в живом журнале комментировал? Или мы одну сторону слушаем?
Да это уже не важно в данной ситуации. Руководство компании дало директиву програмисту работать с конторой. Он отказывается и не хочет идти на уступки. В конце концов даже если он 100% прав в данной ситуации то он все равно не имеет никакого права соботировать проект и приносить компании убытки. Его наняли делать работу — не согласен с текущим пложением дел или организацией работы — попытайся исправит. Не получилось — увольняйся если считаешь что прав или иди на компромис. По этой причине я думаю что мнение програмиста в данной стадии развития конфликта уже не имеет особого значения.
1/14/2014 9:29 PM, _ABC_ пишет:
> Я бы тоже так решил. Но менеджер считает, что без прогера > сорвут сроки. Как будто с ним не сорвут.
Сроки сорваны уже, даже если кто верит в другое. А менеджер там очень
умный человек в этом случае, точь в точь, как белорусское правительство.
> P.S. Я к этой ситуации отношения не имею, если что. Это чисто этюд для > меня.
Хочешь бесплатный совет — если ты не один из участников крысиных бегов
не лезь туда. И даже не более открыто ни за одного из участников, а то
внезапно сам там окажешься.
1/15/2014 6:57 AM, Cyberax пишет:
> Тут неизвестно что нужно сделать: сдать проект и забыть или дальше с ним > работать.
А если директор уже потирает руки от предвкушения новенького поршекаен?
Не зная ситуации в деталях на месте подсказать что-то невозможно.
1/15/2014 9:07 AM, kostik78 пишет:
> Да это уже не важно в данной ситуации. Руководство компании дало > директиву програмисту работать с конторой. Он отказывается и не хочет > идти на уступки. В конце концов даже если он 100% прав в данной ситуации > то он все равно не имеет никакого права соботировать проект и приносить > компании убытки. Его наняли делать работу — не согласен с текущим > пложением дел или организацией работы — попытайся исправит. Не > получилось — увольняйся если считаешь что прав или иди на компромис.
Как бы типичная картинка: "я начальник, ты дурак" не лучший вариант
жизнедеятельности конторы.
Ладно, я тебе нарисую веселее ситуацию: есть очень хороший программист,
но он не хочет делать некий проект, в том числе и по причине того, что
не не специалист в этой узкой части и проект ему не нравиться. Что
делать с этим программистом, поручить ему другой проект (такой есть и не
один) или уволить программиста.
З.Ы. Да, если попытаешься перейти на личности, то так и скажу, да
участвовал в сей ситуации правда лет 15 назад — так что уже давно и
конторы той нет. Так что ситуация достаточно типичная, но не привязанная
ни к какой конторе.
Здравствуйте, gandjustas, Вы писали:
G>Тестер физически не может отловить все. Более того эффективность тестирования не так высока, как принято считать. Ловит от силы 30% дефектов. Остается только надеятся что подрядчик сам отловит остальные 70%.
Зависит от эффективности тестирования. Повторюсь еще раз: если у тестировщика нет плана тестирования, автоматических тестов и т.д. и он просто жмет по кнопочкам и проверяет на небольших объемах данных, то да. Он хрен чего найдет.
Если же у него это все есть, то он отловит значительно больше чем 30% ошибок. У нас вот тестировщики отлавливают около 80%. Потому что составляют план тестирования, что где как. Так же примерно прикидывают на какие компоненты системы может повлиять то или иное изменение и тестируют эти компоненты тоже.
G>>>Смысла нет держать тестеров, если они в среднем выходят дороже программистов. SK>>Хорошие тестировщики стоят дорого, у меня есть примеры, где они получают 80-100 евро в час. Хоть и называются они консультантами или еще как-то, но на самом деле являются тестировщиками и не более того. G>Консультантами вообще все подряд называются. Я вот видел как умный заказчик тупо вычеркивал работы тестировщиков по 80 евро в час из сметы, говорил что пусть кодеры тестят, они дешевле получались.
Мы выставляем счет за разработчика и тестировщика одинаковый и 129 евро в час. Никто еще не вычеркивал. Технический руководитель проекта и менеджер проекта оцениваются в 150 евро в час.
А кодеры такого натестят, что и 10% ошибок не отловят и потом заказчику еще это дороже все может обойтись. Как обычно. Скупой платит дважды.
G>Если ты РП, то тебе и не нужно это делать. Но это значит что не ты занимаешься приемкой, а тестер.
Может быть с точки зрения тестировщика да. Но с точки зрения вышестоящего начальства нет. Если что мозги будут мыть мне, а не тестировщику, а если я еще вдруг надумаю вину не него слить (типа да он плохой тестер), то получу еще 3 мешка люлей дополнительно, со словами "да ты лошара, оказывается, полный. Даже работу тестировщика организовать не можешь" и т.д.
G>Моя практика показала что тестеры плохо с этим справляются. Слишком мало они находят и слишком медленно это делают.
Значит нет организации у них и нет плана тестирования. Или просто они по натуре не тестировщики.
G>Тестеры эффективно работают как UAT, а за качество отвечают программисты, в том числе за качество кода подрядчиков.
С какой стати разработчик в моей команде должен нести ответсвенность за код, который он не писал? К тому же это еще и код подрядчика. Если я только намекну своим разработчикам о просмотре кода подрядчика меня сразу же он отправит в эротическое пешее путешествие и будет полностью прав. Это не его работа и не его обязанности и ему за это не платят.
Из меня, конечно, телепат хреновый, но у меня устойчивое впечатление, что ты в конторе делаешь все за всех и если что все шишки спихнут полностью на тебя.
Ты там случаем бухгалтерию не ведешь?
V>"Ну как ты понять не можешь" ((С) известно чье), а вдруг они тебя V>обманывают в говнокод подсовывают.
Да за ради Бога. Главное, чтобы работало как мне надо, а там пусть хоть код в столбик пишут.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>Тестер физически не может отловить все. Более того эффективность тестирования не так высока, как принято считать. Ловит от силы 30% дефектов. Остается только надеятся что подрядчик сам отловит остальные 70%. SK>Зависит от эффективности тестирования. Повторюсь еще раз: если у тестировщика нет плана тестирования, автоматических тестов и т.д. и он просто жмет по кнопочкам и проверяет на небольших объемах данных, то да. Он хрен чего найдет. SK>Если же у него это все есть, то он отловит значительно больше чем 30% ошибок. У нас вот тестировщики отлавливают около 80%. Потому что составляют план тестирования, что где как. Так же примерно прикидывают на какие компоненты системы может повлиять то или иное изменение и тестируют эти компоненты тоже.
Есть же статистика, еще у макконелла, которая говорил что такие тесты ловят 40%. Может приложения настолько простые, что в вашем случае тестами можно больше покрыть.
G>>Если ты РП, то тебе и не нужно это делать. Но это значит что не ты занимаешься приемкой, а тестер. SK>Может быть с точки зрения тестировщика да. Но с точки зрения вышестоящего начальства нет. Если что мозги будут мыть мне, а не тестировщику, а если я еще вдруг надумаю вину не него слить (типа да он плохой тестер), то получу еще 3 мешка люлей дополнительно, со словами "да ты лошара, оказывается, полный. Даже работу тестировщика организовать не можешь" и т.д.
И они будут правы. Тем не менее приемкой занимается тестер, а не ты.
G>>Моя практика показала что тестеры плохо с этим справляются. Слишком мало они находят и слишком медленно это делают. SK>Значит нет организации у них и нет плана тестирования. Или просто они по натуре не тестировщики.
Есть план. Но это не помогает когда воссоздать внешние условия сложно.
G>>Тестеры эффективно работают как UAT, а за качество отвечают программисты, в том числе за качество кода подрядчиков. SK>С какой стати разработчик в моей команде должен нести ответсвенность за код, который он не писал? К тому же это еще и код подрядчика. Если я только намекну своим разработчикам о просмотре кода подрядчика меня сразу же он отправит в эротическое пешее путешествие и будет полностью прав. Это не его работа и не его обязанности и ему за это не платят.
Потому что разработчик, может лучше качество обеспечить в случае нетривиального приложения.
Не факт конечно что захочет.
SK>Из меня, конечно, телепат хреновый, но у меня устойчивое впечатление, что ты в конторе делаешь все за всех и если что все шишки спихнут полностью на тебя. SK>Ты там случаем бухгалтерию не ведешь?
Наоборот, я ниче не делаю и получаю деньги.
1/15/2014 11:23 AM, SkyKnight пишет:
> Да за ради Бога. Главное, чтобы работало как мне надо, а там пусть хоть > код в столбик пишут.
Тогда ты плохо русскоязычных манагеров знаешь. Да, ты какое-то просто
исключение.
1/15/2014 11:38 AM, gandjustas пишет:
> Есть же статистика, еще у макконелла, которая говорил что такие тесты > ловят 40%. Может приложения настолько простые, что в вашем случае > тестами можно больше покрыть.
А может у того макконела ручки такие (такая организация труда была и
тестирование такое же).
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 11:38 AM, gandjustas пишет:
>> Есть же статистика, еще у макконелла, которая говорил что такие тесты >> ловят 40%. Может приложения настолько простые, что в вашем случае >> тестами можно больше покрыть. V>А может у того макконела ручки такие (такая организация труда была и V>тестирование такое же).
Там статистика по тысячам проектов.
G>Есть же статистика, еще у макконелла, которая говорил что такие тесты ловят 40%.
Статистика, она вот такая зараза. К примеру один тестировщик ловит 10%, другой 80%. В среднем да, 45%.
G>И они будут правы. Тем не менее приемкой занимается тестер, а не ты.
Еще раз. С точки зрения тестировщика — да, с точки зрения вышестоящего начальства — нет. Обычно считается (официально) принимает тот, кто несет потом за это ответственность. Ответсвенный, конечно, может это делегировать ниже, но от этого его ответсвенность перед вышестоящим начальством не уходит ни куда.
G>Есть план. Но это не помогает когда воссоздать внешние условия сложно.
У нас тестируются на данных максимально приближенных к реальным. Поэтому можно на тестах покрыть много чего. Но все, конечно, не покроешь.
G>Потому что разработчик, может лучше качество обеспечить в случае нетривиального приложения. G>Не факт конечно что захочет.
И как поможет ревью, если в системе несколько исполняемых файлов, которые между собой разными путиями коммуницируют (кто-то по TCP/IP, кто-то через файлы, кто-то через базу данных). В этом случае ревью поможет чуть менее, чем ничем. Или если в программе несколько потоков, то гонки между ними при ревью отловить почти что невозможно, ну разве что у человека в голове компилятор зашит. К тому же, как уже сказали, надо точно понимать, что происходит в коде.
А чтобы понять, что написали 4 человека, весьма и весьма сложно.
Просто прочитать его как книжку смысла не иммет, разве что отловятся ошибки типа
int i = 0;
for ( i = 0; i < n; i++)
{
....
for ( i = 5; i < m; i++ )
{
}
....
}
Но и при тестировании может показать, что в таком-то модуле при таких-то действиях выходные данные не те, которые нужны и дальше уже программисты ищут ошибку.
Я, конечно, не хочу занижать твои способности, если ты правда при ревью видишь все ошибки и довольно быстро их находишь, то в твоем случае действительно может быть так и лучше делать. Я, например, слету в чужой код врубиться не смогу. Даже довольно простые функции мне надо сначала посмотреть, потом посмотреть места где она вызывается и только потом принять решение ошибка там или нет. Так что тут может только на одну функцию у меня уйти от 20 мин до 1 часа и при куче кода в пару мегов я просто никогда приемку не закончу. К тому же кода плагинов к нашей системе у нас нет. От 1го есть, да и то, потому что эту фирму мы купили.
G>Наоборот, я ниче не делаю и получаю деньги.
Молодец, хорошо устроился
1/15/2014 12:10 PM, gandjustas пишет:
> Там статистика по тысячам проектов.
Что-то мне не вериться, что Макконел настолько глуп, чтобы подобное
написать, про тысячи проектов. Или глуп?
Ибо бред это и не более про тысячи проектов.
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 12:10 PM, gandjustas пишет:
>> Там статистика по тысячам проектов. V>Что-то мне не вериться, что Макконел настолько глуп, чтобы подобное V>написать, про тысячи проектов. Или глуп? V>Ибо бред это и не более про тысячи проектов.
А ты первоисточник прочитай, там и ссылка на оригинальное исследование, и само исследование вполне достойное. Довольно глупо отрицать его результаты
1/15/2014 1:48 PM, gandjustas пишет:
> Вот тебе краткая выжимка — > http://gandjustas.blogspot.com/2013/07/code-review-vs-testing.html > > Вообще ошибаться не страшно, страшно не признавать ошибки и называть > всех вокруг идиотами.
Ну тогда тебе простой вопрос. Как определялось полное количество ошибок
в проекте?
Лично я не могу даже представить способа определить это?
Т.е. пойдем от печки, что значит его циферки в процентах, надеюсь не то,
что в известных анекдотах про проценты.
Ну и следующий вопрос — ошибка ошибке рознь, одна ошибка приводит
программу в состояние неработоспособности или неправильной работы, а
другая всего-лишь о том, что кнопка не тем цветом нарисована. Это к
тому, что какие ошибки учитывать в этой оценке, а какие нет?
Ну и сразу еще вопрос. Даже если мы каким-то фантастическим образом
смогли найти все ошибки в проекте. Но в одном 99% ошибки уровня "не тот
цвет", а в другом 99% ошибки уровня "не работает и работает не
правильно". Я так понимаю, что это все учтено и отражено в той книжке?
З.Ы. Вопросы тебе, потому как ты привел этого авторитета, как
доказательство. Ты его прекрасно изучил и понимаешь все, что он написал
и поэтому сможет кратко и четко ответить.
З.З.Ы.
Пока опущу вопрос откуда у него взялись тысячи проектов, да еще и со
столь глубоким их анализом — это потом.
