Есть проект, который уже пол года выполняет сторонняя ИТ-фирма подрядчик.
А программист Д – с нашей стороны приемщик работ, текстов и всего проекта.
Месяц назад они — наш программист и подрядчик поссорились.
Теперь программист решил всем назло, сделать всё самостоятельно с помощью одного своего помощника.
...
И я попробовал убедить программиста, предложив такой вариант:
1. Он остаётся техническим руководителем проекта, делает всё, что хочет.
2. Но он обязать принимать работы и дать возможность подрядчику работать в соответствии с ТЗ.
Позиция программиста:
Я же сам готов всё сделать. Это будет бесплатно и гораздо лучше, чем сделает подрядчик.
Нужно немедленно разорвать контракт с подрядчиком.
Тогда я (программист) берусь все сделать через месяц и совершенно бесплатно ( за зарплату), только ко мне никто не должен лезть и мешать.
...
Я говорю:
— Интересы предприятия определяет Директор. Это правильный путь. Если Директор определил, что надо работать с подрядчиком, то надо либо подчиниться, либо увольняться. Недопустимо и неправильно молча делать вид, что подчиняешься приказу, но на самом деле пытаться угробить работу подрядчика и продвинуть свою.
Программист говорит:
— Интересы предприятия в том, чтобы эффективно, качественно сделать проект. Директор просто ошибается, нужно ему доказать, что он не прав и убедить изменить решение.
Я отвечаю:
— Есть классический порядок, который надо придерживаться в работе. На этапе обсуждения можно и нужно спорить и доказывать. Но после того, как решение принято, нужно его исполнять. Его тоже можно обжаловать, но только параллельно с выполнением.
...
Вопрос классический:
— Что делать?
При условии, что надо через месяц сдавать проект и при условии, что хочется сохранить подрядчика?
Там еще более 300 комментов. Выжимка:
* уволить программиста — не сдадим проект в срок
* пойти на поводу программиста — не сдадим проект в срок + поощрение шантажа
* убедить программиста работать с подрядчиком — не убеждается
* выпереть программиста, повысить помощника — помощник не до конца в теме
Еще у eao197 есть развернутый комментарий на тему, почему "я начальник — ты дурак" иногда очень правильно
1. Ваш начальник сам получил недвусмысленные указания без каких-либо пояснений и объяснений.
2. У него больше информации. (которую он не хочет или не может сообщать вам)
3. Ваше мнение может стоить гораздо меньше, чем вам кажется.
4. Руководитель действительно может знать и уметь больше чем вы.
У Евгения кстати и парочка местных старожилов отметилась
Здравствуйте, enji, Вы писали:
E>Позиция программиста: E>Я же сам готов всё сделать. Это будет бесплатно и гораздо лучше, чем сделает подрядчик. E>Нужно немедленно разорвать контракт с подрядчиком. E>Тогда я (программист) берусь все сделать через месяц и совершенно бесплатно ( за зарплату), только ко мне никто не должен лезть и мешать.
Ууууу...
E>Вопрос классический: E>- Что делать?
Гнать нахрен. Минимизация ущерба и потерь времени.
E>При условии, что надо через месяц сдавать проект и при условии, что хочется сохранить подрядчика?
Сроки уже считай будут завалены.
E>Там еще более 300 комментов. Выжимка: E>* уволить программиста — не сдадим проект в срок E>* пойти на поводу программиста — не сдадим проект в срок + поощрение шантажа
Тут патовая ситуация. И так и так сроки будут сорваны. Вопрос с объёме сопуствующего геморроя.
E>А вы чего думаете?
Где то так.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, enji, Вы писали:
E>Наткнулся на интересное
Опытный менеджер, чо: его программист поцапался с подрядчиком и не хочет с ним работать, в качестве аргумента для убеждения программиста применяется отсылка к авторитету директора, мол, как он сказал, так и будет, а тебя, с*ка, никто не спрашивал; это, ясен пень, не убеждает программиста, тогда менеджер пишет на форуме, что, мол, уволить бы его, да у проекта дедлайн скоро.
Если программист еще не ходит по собеседованиям, то он дурак: его сделают виноватым при любом раскладе.
Обобщая.
По моим наблюдениям, фирмы делятся на "я начальник — ты дурак", где инициатива наказуема (как в вышеописанном случае) и нормальные, где инициатива поощряется, а начальство в состоянии снизойти и объяснить принятые решения, даже если приняты они на основании одной лишь интуиции, по-русски это называется авторитет — прекрасная замена формуле "я начальник — ты дурак".
Создать ситуацию когда один человек ключевой на проекте, а остальные не в теме, и не знать, что на проекте происходит, пока не грянет гром, верх некомпетентности. Что делать вопрос сложных, мало данных. Я бы для начала послушал программиста.
E>Еще у eao197 есть развернутый комментарий на тему, почему "я начальник — ты дурак" иногда очень правильно
У уважаемого Евгения опыта руководства, увы, маловато, да и то по результатам его управленческой деятельности ему пришлось с родной конторой, в которой он провел черт знает сколько лет, распрощаться (это кстати и тебе урок). При этом, то что на он написал, он на свою ситуацию отчего-то не проецирует, мысли, что решение о его увольнении принимал человек более компетентный, чем он, и располагающей большей информацией, чем у него, он не допускает
Здравствуйте, enji, Вы писали:
E>А вы чего думаете?
Если менеджер думает в терминах "программист поссорился с заказчиком", этого менеджера стоит уволить как профнепригодного. Ну или послать учиться модной сейчас конфликотлогии. Внешние коммуникации это ответственность исключительно менеджера. Если он допускает такую ситуацию в своем проекте, зачем он тогда нужен?
Что касается проекта, то при наличии денег тут вообще нет никакой проблемы: снимаем приемку с программиста и передаем внешнему аудитору. Или вообще обходимся без приемки раз уж мнение программиста нам не интересное, главное чтобы проект был принят за месяц.
Здравствуйте, MTD, Вы писали:
MTD>Создать ситуацию когда один человек ключевой на проекте, а остальные не в теме, и не знать, что на проекте происходит, пока не грянет гром, верх некомпетентности. Что делать вопрос сложных, мало данных. Я бы для начала послушал программиста.
Это да. Кстати pvn123 вообще говоря посторонний человек, у программиста есть свое начальство, которое вероятно и ответственно за сложившуюся ситуацию
MTD>У уважаемого Евгения опыта руководства, увы, маловато, да и то по результатам его управленческой деятельности ему пришлось с родной конторой, в которой он провел черт знает сколько лет, распрощаться (это кстати и тебе урок).
Подробности, увы, неизвестны. хз, почему расстались, кто виноват и можно ли было сделать по другому.
MTD>При этом, то что на он написал, он на свою ситуацию отчего-то не проецирует, мысли, что решение о его увольнении принимал человек более компетентный, чем он, и располагающей большей информацией, чем у него, он не допускает
Он на тему своего увольнения вообще мало писал, тут, по моему, твои домыслы
Здравствуйте, artem.komisarenko, Вы писали:
AK>Опытный менеджер, чо: его программист поцапался с подрядчиком и не хочет с ним работать, в качестве аргумента для убеждения программиста применяется отсылка к авторитету директора, мол, как он сказал, так и будет, а тебя, с*ка, никто не спрашивал; это, ясен пень, не убеждает программиста, тогда менеджер пишет на форуме, что, мол, уволить бы его, да у проекта дедлайн скоро. AK>Если программист еще не ходит по собеседованиям, то он дурак: его сделают виноватым при любом раскладе.
Менеджер там конечно профукал момент, когда можно вмешаться и сохранить сроки. С другой стороны программист, по словам менеджера, занимается диверсиями, что тоже не гуд...
AK>По моим наблюдениям, фирмы делятся на "я начальник — ты дурак", где инициатива наказуема (как в вышеописанном случае) и нормальные, где инициатива поощряется, а начальство в состоянии снизойти и объяснить принятые решения, даже если приняты они на основании одной лишь интуиции, по-русски это называется авторитет — прекрасная замена формуле "я начальник — ты дурак".
Нужен какой-то баланс. С одной стороны — мнение опытных исполнителей важно, с другой — отвечать то за все руководству.
Здравствуйте, Miroff, Вы писали:
M>Если менеджер думает в терминах "программист поссорился с заказчиком", этого менеджера стоит уволить как профнепригодного. Ну или послать учиться модной сейчас конфликотлогии. Внешние коммуникации это ответственность исключительно менеджера. Если он допускает такую ситуацию в своем проекте, зачем он тогда нужен?
А можно поподробней? Т.е. программист с заказчиком вообще напрямую не общается? Ну если есть куча программистов на проекте — то да, нужна централизованная коммуникация. А если проект = 1 программист, то в чем смысл?
M>Что касается проекта, то при наличии денег тут вообще нет никакой проблемы: снимаем приемку с программиста и передаем внешнему аудитору. Или вообще обходимся без приемки раз уж мнение программиста нам не интересное, главное чтобы проект был принят за месяц.
Вероятно хотят сэкономить. Внешний аудитор и свой программист на зарплате — это сильно разные затраты. Опять же как я понял. этот проект потом будет развиваться, т.е. аудитору придется платить и дальше, или же все равно нанимать другого программиста и вводить его в курс
Здравствуйте, enji, Вы писали:
E>Менеджер там конечно профукал момент, когда можно вмешаться и сохранить сроки. С другой стороны программист, по словам менеджера, занимается диверсиями, что тоже не гуд...
Не нашел там диверсий. Вижу, что по две недели программист с подрядчиком не могут довогориться из-за какой-то фигни. Делать выводы о диверсиях не заслушав обе стороны довольно глупо
E>Нужен какой-то баланс. С одной стороны — мнение опытных исполнителей важно, с другой — отвечать то за все руководству.
В данном случае за все ответит программист, которого уволят. Притом обратите внимание, в посте не раскрывается кто из них двоих, из подрядчика и программиста чудак, или может быть чудаки оба или никто. Это значит, что ситуация инвариантна относительно чудаковости действующих лиц, т. е. программист останется крайним при любых раскладах. Комменты на эту тему можно просто на цитаты расхватать:
Программиста уволить.
Сначала он докзывает, что он крутой подрядчику. Потом он возомнит себя гением вообще, и будет требовать к себе снисходительного отношения, повышения зарплаты и т.д., и т.п... На том простом основании, что он гений а вы все вокруг серые посредственности.
Да, дилеммка. Программист насколько я поняла молод и его юношеский максимализм вряд ли удастся нейтрализовать. Думаю, нужно еще раз ему объяснить, что есть субординация и приказы начальства не обсуждаются. Ели ему директор не указ, то завтра черте что ему в голову придет. А вообще припугнуть надо-увольнением)
А сейчас взять подписку с него, что работу выполнит в срок, без ошибок, а иначе накажут рублём.
А вдруг он за это время заболеет, мало ли — шёл, упал, очнулся — гипс на руке, не дай Бог.
Он что дитё неразумное что ли, и не понимает, что подводит фирму.
Вот когда станет, если станет директором, тогда и будет принимать решения, а пока, он лишь — НАНЯТ на работу!!!
Я ему говорю:
— Но, логично, что именно Директор знает, что в интересах фирмы, а что нет. Ты — можешь многого не знать.
А он:
— Так скажите мне. Вы что, хотите из меня раба бессловесного сделать?
Я даже оторопел:
— Есть же служебная информация. Одному — одна информация, другому — другая, есть доступы.
Он этого не понимает. Чует обиду в любой попытке ограничить его права по проекту.
И на закуску самое прекрасное от ТС:
Увольнять после сдачи — это всё равно придется.
Как его убедить сдать проект нормально?
Здравствуйте, enji, Вы писали:
E>А можно поподробней? Т.е. программист с заказчиком вообще напрямую не общается?
Не обязательно, менеджер может делегировать какую-то часть внешнего взаимодействия своим подчиненным, но это не снимает с него ответственности. Хороший менеджер должен был не пускать приемку на самотек, а держать руку на пульсе.
Почему бы не попросить программиста составить детальный план, в котором он докажет, что сделает за месяц.
Чтобы доказать что сделает, пусть оформит документацию (список фич).
Чтобы доказать, что фичи нужные, пусть оформит список требований (и кто за эти требования отвечает).
Как только он попытается это проделать, вопросы, почему требуется много времени, у программиста отпадут.
Думаю что проблема, которая и яйца выеденного не стоит, определяется желанием менеджмента сдать проект чётко в срок.
Если здесь ослабить это желание то всё делается запросто — программист уходит, его помошнику увеличивается зп, проект
допиливается с опозданием в пару месяцев — я так понял что проект уже вот вот будет сдан, соответственно допиливать там
не очень много, возможно какие то фичи оставить на дальнейшую поддержку. Ну и раз пошла такая пьянка
то скорее всего проект уже в любом случае не будет сдан в срок, просто пока менеджмент не хочет смотреть этой правде в глаза.
Это если судить о ситуации только по информации от одной стороны. Послушать бы другую, возможно там всё куда интереснее.
Здравствуйте, enji, Вы писали:
E>Еще у eao197 есть развернутый комментарий на тему, почему "я начальник — ты дурак" иногда очень правильно
E>А вы чего думаете?
я думаю что если начальник такой умный, то ему и подчиненные не нужны.
Здравствуйте, enji, Вы писали:
E>А можно поподробней? Т.е. программист с заказчиком вообще напрямую не общается? Ну если есть куча программистов на проекте — то да, нужна централизованная коммуникация. А если проект = 1 программист, то в чем смысл?
Смысл в том, чтобы сапожник не пек пироги, а пирожник не занимался сапогами. Это на вскидку. Еще — менеджер( как начальник) должен договариваться с обеими сторонами и принимать решения что и как делать, а не его подчиненный.
Здравствуйте, enji, Вы писали:
E>А вы чего думаете?
Что за проект ? Сомневаюсь, что молодой, малоопытный программист способен сделать какой-либо серьезный проект в одиночку за месяц.
Надо это ему просто объяснить. Это лишь поначалу кажется, что стоит ночку и выходные посидеть и все напишется.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Что за проект ? Сомневаюсь, что молодой, малоопытный программист способен сделать какой-либо серьезный проект в одиночку за месяц.
Я с вас, телепатов, не перестаю удивляться. А ну как он крайне опытный, да и проект к тому же ему очень хорошо знаком, есть наработанная база.
Здравствуйте, enji, Вы писали:
E>А вы чего думаете?
Я думаю что менеджер — лошара.
1) менеджер должен выяснить причину конфликта, попытаться устранить конфликт, а не чье-то мнение.
2) гипотезу программиста очень легко проверить, дав ему сделать часть работ и сравнить реальные результаты. Буквально за неделю можно получить объективный результат.
Также думаю что программист не подходит для этой работы. Приемка требует много чтения кода, а программисты больше любят писать код. Поэтому рано или поздно программиста придется заменить.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, enji, Вы писали:
E>>А вы чего думаете?
_O_>Что за проект ? Сомневаюсь, что молодой, малоопытный программист способен сделать какой-либо серьезный проект в одиночку за месяц. _O_>Надо это ему просто объяснить. Это лишь поначалу кажется, что стоит ночку и выходные посидеть и все напишется.
А с чего ты взял что он молодой и малоопытный? Это домыслы, в оригинальном посте автор об этом не писал.
Я, кстати, вживую видел как один толковый программист делал быстрее и лучше чем 3 программиста подрядчиков. Опыт примерно одинаковый был.
S>Почему бы не попросить программиста составить детальный план, в котором он докажет, что сделает за месяц. S>Чтобы доказать что сделает, пусть оформит документацию (список фич). S>Чтобы доказать, что фичи нужные, пусть оформит список требований (и кто за эти требования отвечает). S>Как только он попытается это проделать, вопросы, почему требуется много времени, у программиста отпадут.
Ага, потому что программист уволится. Конечно, если он не дурак. Опытные программисты прекрасно понимают — как только у них требуют работать за себя, а также за аналитиков, program manager'ов, юзабилистов и других персон, это лишь означает, что их довольно бездарно "разводят".
Методика разводки классическая: "ты пока выполняй свои старые обязанности, и в свободное от этого время составляй план, список фич и прочее".
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, enji, Вы писали:
G> Приемка требует много чтения кода
читать код обычно приходится когда нет документации и сам код небрежно написан. у меня есть опыт участия в приемке. на код там вообще никто не смотрел. сначала долго и вдумчиво читали спецификацию с кучей "самопальных" аббревиатур и тонной диаграмм, иллюстрирующих процесс черточками и стрелочками с мелким-мелким шрифтом.
исполнителю давался тестовый набор данных. а написанный им код тестировался на другом наборе, который ему стремились не показывать, чтобы он не подгонял решение под ответ. никто кроме автоматических верификаторов код не читал. при этом значительная часть кода была машинно-сгенерированной, но отдавать генератор исполнитель не спешил, ибо это его ноу-хау. и это было одним из аргументов против него, т.к. лучше за день написать все самим чем за час получить машинную выдачу.
хотя вы правы. приемка кода выходит за грани разума обычного программиста и требует навыков владения определенными процедурами в которых больше бюрократии чем инженерной мысли.
кстати, даже хорошо структурированный и комментированный код читать дольше чем писать и еще предметной областью владеть надо. можно нагуглить исходники арифметического компрессора (алгоритм один из самых простых и оно укладывается в сотню строк кода). долго же вы будете его читать если раньше с таким не сталкивались. а если сталкивались и знаете, то зачем это кому-то поручать?
обычно подрядчикам поручают то, что сами либо не знают как, либо рука не набита/наработок нет. довольно часто становится, что исполнитель пишет на языке не знакомом для команды заказчика (или это знакомство очень поверхностно без углублений в трудные места).
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
а для политики есть соответствующий форум, постарайся не забыть об этом в следующий раз.
E>* уволить программиста — не сдадим проект в срок
Увольнять надо не программиста, а горе-менеджера.
Потому что:
1. Вместо того, чтобы заниматься коммуникациями с внешними поставщиками, менеджер всё спихнул на кого-то.
2. Менеджер не в курсе деталей конфликта с внешней стороной.
3. Менеджер не соизволил погасить конфликт в зародыше, дал конфликту созреть и вырасти в открытое противостояние.
4. Менеджер винит свою команду, вместо того, чтобы ее защищать.
Позволю себе лирическое отступление и сравнение подхода к менеджменту и руководству у представителей разной ментальности. На примере политики США и России. США за их внешнюю политику ненавидит пол-мира. Потому что в случае чего, разборки будут не на территории США. Граждане США будет довольны. Потому что государство их защищает.
Как это происходит в России? Ограбить соседние государство чиновничья верхушка России не в силах. И, ничтоже сумняшеся, грабит собственный народ. В случае чего, граждане России первыми же и попадают под удар. Бей своих, чтобы чужие боялись.
После такого лирического отступления становится проще объяснить и поведение упомянутого "менеджера". Вероятно, у него нет рычагов влияния на внешних поставщиков. Равно как нет и желания (умения?) искать дипломатическое решение. Куда проще обвинить в саботаже собственного работника. Свалить провал на него.
E>* убедить программиста работать с подрядчиком — не убеждается
Этот пункт надо разобрать с вниманием к деталям. Что явилось началом конфликта? Почему он возник? Почему он не разрешается? Какие аргументы со стороны программиста? Имеет ли он картину происходящего? Понимают ли все стороны, почему было принято именно такое решение, какое было принято? Не может ли так случиться, что настойчивость руководства есть лишь проявление твердолобости вида "мы всё решили, и раз мы начальство, мы не можем ошибаться".
E>* выпереть программиста, повысить помощника — помощник не до конца в теме
Каждый раз как вижу такие забавные "рекомендации", сразу вспоминаю одного очень академичного коллегу, с которым имел счастье работать. Он в таких случаях начинал цитировать Крылова:
Проказница-Мартышка,
Осёл,
Козёл,
Да косолапый Мишка
Затеяли сыграть Квартет.
Разумеется, он, как положено истинно воспитанному человеку, не дочитывал до конца. Но намек был более чем прозрачен:
А вы, друзья, как ни садитесь,
Всё в музыканты не годитесь».
Здравствуйте, enji, Вы писали:
E>Там еще более 300 комментов. Выжимка: E>* уволить программиста — не сдадим проект в срок E>* пойти на поводу программиста — не сдадим проект в срок + поощрение шантажа E>* убедить программиста работать с подрядчиком — не убеждается E>* выпереть программиста, повысить помощника — помощник не до конца в теме
Очень важно еще уметь читать то что НЕ написано.
1) Почему так получилось что весь проект завязан на одного программиста?
2) Где же тестеры? Как вообще осуществляется приемка? Почему её делает один программист?
3) Почему нет формализованной процедуры приемки? Чем РП вообще занимается на этом проекте?
4) В комментах пару раз проскочило что ТЗ на самом деле ХЗ и сделать по нему ничего нельзя, нужен носитель знаний, очень странно что это программист, а не аналитик. Тоже фейл.
5) Вполне возможно что программист в этой ситуации прав и он быстрее будет писать код сам, чем принимать от подрядчика. Это не значит что подрядчики плохие, это скорее всего, процесс плохой.
Могу сделать вывод что фейл был обеспечен сильно заранее, а конфликт программиста и подрядчиков лишь триггер. Должно очень повезти, чтобы такие фейлы не случались.
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, enji, Вы писали:
G>> Приемка требует много чтения кода М>читать код обычно приходится когда нет документации и сам код небрежно написан. у меня есть опыт участия в приемке. на код там вообще никто не смотрел. сначала долго и вдумчиво читали спецификацию с кучей "самопальных" аббревиатур и тонной диаграмм, иллюстрирующих процесс черточками и стрелочками с мелким-мелким шрифтом.
М>исполнителю давался тестовый набор данных. а написанный им код тестировался на другом наборе, который ему стремились не показывать, чтобы он не подгонял решение под ответ. никто кроме автоматических верификаторов код не читал. при этом значительная часть кода была машинно-сгенерированной, но отдавать генератор исполнитель не спешил, ибо это его ноу-хау. и это было одним из аргументов против него, т.к. лучше за день написать все самим чем за час получить машинную выдачу.
Видимо выделенное и было причиной что код не читал.
Я большую при приемке первое что делаю — читаю код. Это же обычно и последнее.
М>кстати, даже хорошо структурированный и комментированный код читать дольше чем писать и еще предметной областью владеть надо. можно нагуглить исходники арифметического компрессора (алгоритм один из самых простых и оно укладывается в сотню строк кода). долго же вы будете его читать если раньше с таким не сталкивались. а если сталкивались и знаете, то зачем это кому-то поручать?
Большинство реализаций алгоритмов из интернета отличается крайне низкой читаемостью. Это делается в угоду быстродействию.
Вот недавно читал код хаффмана на F# в блоге — очень легко, несмотря на то что типов почти нет. А потом для сравнения нагуглил исходник на C, плакал кровавыми слезами, даже студия не помогла.
М>обычно подрядчикам поручают то, что сами либо не знают как, либо рука не набита/наработок нет. довольно часто становится, что исполнитель пишет на языке не знакомом для команды заказчика (или это знакомство очень поверхностно без углублений в трудные места).
Обычно подрядчикам решение слабо формализованной проблемы, а не решение конкретной задачи. От этого и появляются такие посты.
Это практика в России такая, я хз что у вас за океаном творится.
Здравствуйте, SkyDance, Вы писали:
E>>* уволить программиста — не сдадим проект в срок
SD>Увольнять надо не программиста, а горе-менеджера. SD>Потому что: SD>1. Вместо того, чтобы заниматься коммуникациями с внешними поставщиками, менеджер всё спихнул на кого-то. SD>2. Менеджер не в курсе деталей конфликта с внешней стороной. SD>3. Менеджер не соизволил погасить конфликт в зародыше, дал конфликту созреть и вырасти в открытое противостояние. SD>4. Менеджер винит свою команду, вместо того, чтобы ее защищать.
Вообще-то, если перейти по ссылке, то будет ясно, что этому менеджеру поручили разобраться с уже сложившейся
ситуацией. Этакий кризис-менеджер, можно сказать.
Это я к тому, что стоит всё-таки сначала ознакомиться с хотя бы всей доступной информацией перед тем, как
делать выводы.
_AB>Вообще-то, если перейти по ссылке, то будет ясно, что этому менеджеру поручили разобраться с уже сложившейся _AB>ситуацией. Этакий кризис-менеджер, можно сказать.
Речь про предыдущего менеджера, который к этому кризису привёл.
С вашим утверждением про необходимость проверки деталей согласен. К томе же следует выслушать как минимум две стороны. В данном случае четыре — старое руководство, новое, а также стороны-участницы конфликта, суть программист и сторонний подрядчик, плюс пятая сторона — начальство над всеми ними.
Здравствуйте, SkyDance, Вы писали:
SD>1. Вместо того, чтобы заниматься коммуникациями с внешними поставщиками, менеджер всё спихнул на кого-то. SD>2. Менеджер не в курсе деталей конфликта с внешней стороной. SD>3. Менеджер не соизволил погасить конфликт в зародыше, дал конфликту созреть и вырасти в открытое противостояние. SD>4. Менеджер винит свою команду, вместо того, чтобы ее защищать.
+4
но Вас правильно поправили ниже, что это все к прошлому менеджеру, а не к новому.
SD>На примере политики США и России.
здесь надо сделать поправку, что вообще направление управления, отличное от командного, в России появилось недавно. и еще вот только сейчас начали появляться нормальные руководители.
во
Здравствуйте, MTD, Вы писали:
MTD>Я с вас, телепатов, не перестаю удивляться. А ну как он крайне опытный, да и проект к тому же ему очень хорошо знаком, есть наработанная база.
Крайне опытные способно аргументировано убедить начальство в своей правоте и саботировать процесс не будут.
Здравствуйте, artem.komisarenko, Вы писали:
AK>В данном случае за все ответит программист, которого уволят.
Ответит тот, кто потратил деньги с нулевым результатом, если это, конечно, не попил.
А программист просто сменит работу на более приличную. Вообще, если кто-то вдруг в этом программисте узнал себя, то самое лучшее начать срочно искать другую работу, пусть "эффективные менеджеры" сами с собой развлекаются.
Здравствуйте, SkyDance, Вы писали:
SD>Позволю себе лирическое отступление и сравнение подхода к менеджменту и руководству у представителей разной ментальности. На примере политики США и России. США за их внешнюю политику ненавидит пол-мира. Потому что в случае чего, разборки будут не на территории США. Граждане США будет довольны. Потому что государство их защищает. SD>Как это происходит в России? Ограбить соседние государство чиновничья верхушка России не в силах. И, ничтоже сумняшеся, грабит собственный народ. В случае чего, граждане России первыми же и попадают под удар. Бей своих, чтобы чужие боялись.
Поставил минус за политическую аналогию, которая, во-первых, не вписывается в тематику форума, а, во-вторых, по моему мнению, попросту некорректна и не соответствует истине.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, SkyDance, Вы писали:
E>>>* уволить программиста — не сдадим проект в срок
_AB>Вообще-то, если перейти по ссылке, то будет ясно, что этому менеджеру поручили разобраться с уже сложившейся _AB>ситуацией. Этакий кризис-менеджер, можно сказать.
Если это кризис менеджер — то на мой взгляд вывод простой. Предоставить развернутый анализ текущей ситуации вышестоящемоу менеджеру и вынести предложение об увеличений срока проекта и уволнений програмиста. Принимать решение в данной ситуации самому менеджеру не стоит.
G>Вот недавно читал код хаффмана на F# в блоге — очень легко, несмотря на то что типов почти нет. А потом для сравнения нагуглил исходник на C, плакал кровавыми слезами, даже студия не помогла.
Сам принцип кодирования по Хафману довольно прост, и хорошо описан в литературе.
Что бы с ним ознакомится, читать левые бложики совсем не надо, можно например прочесть RFC от gzip, помимо Deflate там описаны все принципы кодирования по Хафману.
Реализаций декодирования довольно много — наиная от примитивных просмотров битов в цикле, заканчивая использованием lookup таблиц. Но в целом там нет ничего сложного, все гениальное — просто.
Здравствуйте, kostik78, Вы писали:
K>Если это кризис менеджер — то на мой взгляд вывод простой. Предоставить развернутый анализ текущей ситуации вышестоящемоу менеджеру и вынести предложение об увеличений срока проекта и уволнений програмиста.
Примерно так бы я и поступил будь я на его месте. Но я не программист и не менеджер.
И есть в связи с этим у меня один вопрос ниже.
K>Принимать решение в данной ситуации самому менеджеру не стоит.
Зачем нужен менеджер, если он боится принимать решения в рамках своей компетенции?
Или это не его компетенция? Но тогда он скорее аудитор, а не менеджер получается?
Здравствуйте, gandjustas, Вы писали:
G>Видимо выделенное и было причиной что код не читал. G>Я большую при приемке первое что делаю — читаю код. Это же обычно и последнее.
Если бы я читал весь код, который нам делают подрядчики, я бы уже давно бы помер.
Просто так скажу, что у нас Warehousing система и для нее есть несколько плагинов, которые делают сторонние фирмы. Так вот, эти плагины на столько гигантские, что прочитать код даже теоритически нереально в короткое время.
Поэтому у меня есть просто несколько наборов тестовых данных, на которых я проверяю очередную версию плагина. Как оно там внутри устроено мне, в прицнипе, даже не интересно. Мне главное, чтобы плагины подрядчика работали, работали быстро и не валились от каждого движения мышкой. Если на своих тестовых наборах я воспроизвожу какой-то баг, то сообщаю об этом подрядчику и даю так же этот набор, чтобы он мог баг воспроизвести и пофиксить.
Если что-то случается на стороне заказчика с этим плагином, то просто беру дамп данных заказчика и отправляю подрядчику.
Да и то, тестирую не я лично сам, а отдаю нашим тестеровщикам. Они это делают куда как лучше меня, а мне еще надо распределить задачи между разработчиками, составить список фич, спланировать, так что время для разработки у меня у самого почти не остается. А тут еще мегабайты кода читать.... Так я совсем никогда домой не попаду.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Крайне опытные способно аргументировано убедить начальство в своей правоте и саботировать процесс не будут.
Это если начальство способно убедиться. Обычно это не так. См. старую истину "я — начальник, ты — дурак". Я на своей шкуре познал "эффективных манагеров" и просто плюнул и ушел сам. Проекты в конторе загнулись. Один — по разработке — я забрал себе, заключив прямой договор с заказчиком. Второй в силу специфики забрать, увы, не могу. Контора сейчас от заказчика огребает по полной.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>Видимо выделенное и было причиной что код не читал. G>>Я большую при приемке первое что делаю — читаю код. Это же обычно и последнее.
SK>Если бы я читал весь код, который нам делают подрядчики, я бы уже давно бы помер. SK>Просто так скажу, что у нас Warehousing система и для нее есть несколько плагинов, которые делают сторонние фирмы. Так вот, эти плагины на столько гигантские, что прочитать код даже теоритически нереально в короткое время. SK>Поэтому у меня есть просто несколько наборов тестовых данных, на которых я проверяю очередную версию плагина. Как оно там внутри устроено мне, в прицнипе, даже не интересно. Мне главное, чтобы плагины подрядчика работали, работали быстро и не валились от каждого движения мышкой. Если на своих тестовых наборах я воспроизвожу какой-то баг, то сообщаю об этом подрядчику и даю так же этот набор, чтобы он мог баг воспроизвести и пофиксить.
Ничего бы с тобой не стало. Средний программист пишет код примерно в 4 раза медленнее, чем средний же программист его читает.
То есть ты бы мог читать код 4-х человек и еще оставалось бы время покодить, подрядчики ведь не по 8 часов пишут.
Очень помогают тулы, особенно на начальном этапе, пока они считают что можно гнать фуфло.
Со временем подрядчики понимают как надо писать и начинают делать быстрее и лучше, тебе придется меньше времени читать их код.
Но ты как раз подтердил мои слова — приемка требует чтения кода, если ты не читаешь код, то можно за эту работу посадить в два раза более дешевого тестера.
SK>Если что-то случается на стороне заказчика с этим плагином, то просто беру дамп данных заказчика и отправляю подрядчику.
SK>Да и то, тестирую не я лично сам, а отдаю нашим тестеровщикам. Они это делают куда как лучше меня, а мне еще надо распределить задачи между разработчиками, составить список фич, спланировать, так что время для разработки у меня у самого почти не остается. А тут еще мегабайты кода читать.... Так я совсем никогда домой не попаду.
А ты зачем нужен в этой схеме работы с подрядчиками? Сам не тестируешь, код не читаешь, что ты вообще в приемке делаешь? Только передаешь туда-сюда?
Здравствуйте, gandjustas, Вы писали:
G>Ничего бы с тобой не стало. Средний программист пишет код примерно в 4 раза медленнее, чем средний же программист его читает. G>То есть ты бы мог читать код 4-х человек и еще оставалось бы время покодить, подрядчики ведь не по 8 часов пишут. G>Очень помогают тулы, особенно на начальном этапе, пока они считают что можно гнать фуфло. G>Со временем подрядчики понимают как надо писать и начинают делать быстрее и лучше, тебе придется меньше времени читать их код.
Все равно не понимаю зачем эти лишние движняки. Есть спецификация. Данные на входе -> данные на выходе за определенное время. Как они это реализуют, на чем, мне, честно говоря, совершенно неинтересно.
А так я представляю как каждый заказчик просматривает код софта, который он покупает.
G>Но ты как раз подтердил мои слова — приемка требует чтения кода, если ты не читаешь код, то можно за эту работу посадить в два раза более дешевого тестера.
Тестировщики не совсем дешевле разработчика. Они примерно одинаково стоят. Ну есть это, конечно, не такой, который просто кнопочки тыкает. Ему надо составить тест план, проверять на различных данных и прочее. В общем это работа совсем не такая легкая как кажется.
G>А ты зачем нужен в этой схеме работы с подрядчиками? Сам не тестируешь, код не читаешь, что ты вообще в приемке делаешь? Только передаешь туда-сюда?
Подписываю документы и несу ответсвенность. Если что, то все шишки на меня. Тестировщиков и разработчиков эти шишки не коснутся.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>Ничего бы с тобой не стало. Средний программист пишет код примерно в 4 раза медленнее, чем средний же программист его читает. G>>То есть ты бы мог читать код 4-х человек и еще оставалось бы время покодить, подрядчики ведь не по 8 часов пишут. G>>Очень помогают тулы, особенно на начальном этапе, пока они считают что можно гнать фуфло. G>>Со временем подрядчики понимают как надо писать и начинают делать быстрее и лучше, тебе придется меньше времени читать их код. SK>Все равно не понимаю зачем эти лишние движняки. Есть спецификация. Данные на входе -> данные на выходе за определенное время. Как они это реализуют, на чем, мне, честно говоря, совершенно неинтересно.
Затем что основные затраты на софт идут на этапе эксплуатации, появляются баги и всякие мелочи, которые надо поправить, очень большую роль играет UX и надежность кода при изменении параметров среды.
Причем тестировать все это непозволительно долго.
За свою практику я не видел кода, для которого было бы достаточно удовлетворения только функциональной спецификации.
Да и банально review ловит больше ошибок, чем тестирование.
SK>А так я представляю как каждый заказчик просматривает код софта, который он покупает.
В заказной разработке нередко клиенты заказывают аудит вашего кода у ваших конкурентов.
G>>Но ты как раз подтердил мои слова — приемка требует чтения кода, если ты не читаешь код, то можно за эту работу посадить в два раза более дешевого тестера. SK>Тестировщики не совсем дешевле разработчика. Они примерно одинаково стоят. Ну есть это, конечно, не такой, который просто кнопочки тыкает. Ему надо составить тест план, проверять на различных данных и прочее. В общем это работа совсем не такая легкая как кажется.
Смысла нет держать тестеров, если они в среднем выходят дороже программистов.
G>>А ты зачем нужен в этой схеме работы с подрядчиками? Сам не тестируешь, код не читаешь, что ты вообще в приемке делаешь? Только передаешь туда-сюда? SK>Подписываю документы и несу ответсвенность. Если что, то все шишки на меня. Тестировщиков и разработчиков эти шишки не коснутся.
Ну то есть ты приемкой то и не занимаешься, просто передастом работаешь.
Фактически качество кода подрядчиков контролирует только тестер.
1/14/2014 10:25 AM, SkyKnight пишет:
> Все равно не понимаю зачем эти лишние движняки. Есть спецификация. > Данные на входе -> данные на выходе за определенное время. Как они это > реализуют, на чем, мне, честно говоря, совершенно неинтересно. > А так я представляю как каждый заказчик просматривает код софта, который > он покупает.
"Ну как ты понять не можешь" ((С) известно чье), а вдруг они тебя
обманывают в говнокод подсовывают.
Здравствуйте, gandjustas, Вы писали:
G>Затем что основные затраты на софт идут на этапе эксплуатации, появляются баги и всякие мелочи, которые надо поправить, очень большую роль играет UX и надежность кода при изменении параметров среды.
Вот в этом и заключается задача тестировщика все еще отловить на этапе приемки. Хороший тестировщик сможет это все отловить, а плохой и нафиг не нужен.
SK>>А так я представляю как каждый заказчик просматривает код софта, который он покупает. G>В заказной разработке нередко клиенты заказывают аудит вашего кода у ваших конкурентов.
Никогда с таким не встречался. Да и даже в заказной работе в договоре исполнитель подпишет так, чтобы код не отдавать.
G>Смысла нет держать тестеров, если они в среднем выходят дороже программистов.
Хорошие тестировщики стоят дорого, у меня есть примеры, где они получают 80-100 евро в час. Хоть и называются они консультантами или еще как-то, но на самом деле являются тестировщиками и не более того.
G>Ну то есть ты приемкой то и не занимаешься, просто передастом работаешь. G>Фактически качество кода подрядчиков контролирует только тестер.
ну оно конечно можно, чтобы все делал один человек. И код писал и тестировал работу подрядчиков и руководил проектом и еще там бухгалтерию вел и все в сроки успевал, только если и будет такой человек, то стоить он будет столько, что дешевле нанять все-таки 4х. Если кто-то думает, что руководитель проекта просто чай на работе гоняет, то он глубоко заблуждается. Поэтому еще раз повторюсь, времени у меня на чтение кода, к тому же чужого.
1/14/2014 10:36 AM, gandjustas пишет:
> Ну то есть ты приемкой то и не занимаешься, просто передастом работаешь.
Вообще-то в отличие от тебя SK выполняет свою работу и не пытается лезть
во все дырки, а вот тебе, вероятнее всего, просто нечем заняться.
Здравствуйте, Vzhyk, Вы писали:
V>1/14/2014 10:36 AM, gandjustas пишет:
>> Ну то есть ты приемкой то и не занимаешься, просто передастом работаешь. V>Вообще-то в отличие от тебя SK выполняет свою работу и не пытается лезть V>во все дырки, а вот тебе, вероятнее всего, просто нечем заняться.
Почему это тебя интересует? Ты хочешь об этом поговорить?
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>Затем что основные затраты на софт идут на этапе эксплуатации, появляются баги и всякие мелочи, которые надо поправить, очень большую роль играет UX и надежность кода при изменении параметров среды. SK>Вот в этом и заключается задача тестировщика все еще отловить на этапе приемки. Хороший тестировщик сможет это все отловить, а плохой и нафиг не нужен.
Тестер физически не может отловить все. Более того эффективность тестирования не так высока, как принято считать. Ловит от силы 30% дефектов. Остается только надеятся что подрядчик сам отловит остальные 70%.
SK>>>А так я представляю как каждый заказчик просматривает код софта, который он покупает. G>>В заказной разработке нередко клиенты заказывают аудит вашего кода у ваших конкурентов. SK>Никогда с таким не встречался. Да и даже в заказной работе в договоре исполнитель подпишет так, чтобы код не отдавать.
Исполнитель с таким договором пойдет нафиг чаще всего. Только недалекий ИТ-менеджер пропустит такой договор.
Я всем клиентам рекомендую всегда оставлять имущественные права на весь код решений.
G>>Смысла нет держать тестеров, если они в среднем выходят дороже программистов. SK>Хорошие тестировщики стоят дорого, у меня есть примеры, где они получают 80-100 евро в час. Хоть и называются они консультантами или еще как-то, но на самом деле являются тестировщиками и не более того.
Консультантами вообще все подряд называются. Я вот видел как умный заказчик тупо вычеркивал работы тестировщиков по 80 евро в час из сметы, говорил что пусть кодеры тестят, они дешевле получались.
Все что ты рассказываешь рассчитано на лохов. Золотые тестеры и не передача кода у любого серьезного заказчика не прокатит.
G>>Ну то есть ты приемкой то и не занимаешься, просто передастом работаешь. G>>Фактически качество кода подрядчиков контролирует только тестер. SK>ну оно конечно можно, чтобы все делал один человек. И код писал и тестировал работу подрядчиков и руководил проектом и еще там бухгалтерию вел и все в сроки успевал, только если и будет такой человек, то стоить он будет столько, что дешевле нанять все-таки 4х. Если кто-то думает, что руководитель проекта просто чай на работе гоняет, то он глубоко заблуждается. Поэтому еще раз повторюсь, времени у меня на чтение кода, к тому же чужого.
Если ты РП, то тебе и не нужно это делать. Но это значит что не ты занимаешься приемкой, а тестер.
Моя практика показала что тестеры плохо с этим справляются. Слишком мало они находят и слишком медленно это делают.
Тестеры эффективно работают как UAT, а за качество отвечают программисты, в том числе за качество кода подрядчиков.
Здравствуйте, gandjustas, Вы писали:
G>Затем что основные затраты на софт идут на этапе эксплуатации, появляются баги и всякие мелочи, которые надо поправить, очень большую роль играет UX и надежность кода при изменении параметров среды. G>Причем тестировать все это непозволительно долго. G>За свою практику я не видел кода, для которого было бы достаточно удовлетворения только функциональной спецификации. G>Да и банально review ловит больше ошибок, чем тестирование.
По моему опыту ревью ловит только стилистические отклонения от Code Standard и потенциальные ошибки, которые просто бросаются в глаза (типа неуместного использования new/delete в С++ коде).
Но такое встречается только у совсем начинающих.
Чтобы выявить более серьезные ошибки приходится вникать в код, понимать, какую задачу этот код решает, как ее решает. А обычно каждый решает свою задачу, на выяснение, чем занимаются вокруг, времени нет. Т.е. трудозатраты на ревью получаются лишь немногим меньше, чем написание этой функциональности с нуля самостоятельно. И на такое никто время не выделяет.
Поэтому согласен со SkyKnight, что за внутренности плагина пусть отвечает исполнитель, главное, чтобы тесты проходили.
_____________________
С уважением,
Stanislav V. Zudin
SD>Речь про предыдущего менеджера, который к этому кризису привёл.
То есть, пригласили тебя как кризис-менеджера разрулить ситуацию. Ты посмотрел и говоришь,
что нужно уволить предыдущего менеджера по четырем причинам.
Того менеджера уже нет, отвечают тебе. Тебя и пригласили поэтому, собственно говоря.
А вопрос в том, что делать в сложившейся ситуации.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, gandjustas, Вы писали:
G>>Затем что основные затраты на софт идут на этапе эксплуатации, появляются баги и всякие мелочи, которые надо поправить, очень большую роль играет UX и надежность кода при изменении параметров среды. G>>Причем тестировать все это непозволительно долго. G>>За свою практику я не видел кода, для которого было бы достаточно удовлетворения только функциональной спецификации. G>>Да и банально review ловит больше ошибок, чем тестирование.
SVZ>По моему опыту ревью ловит только стилистические отклонения от Code Standard и потенциальные ошибки, которые просто бросаются в глаза (типа неуместного использования new/delete в С++ коде).
Это значит что ты код смотрел, а не читал.
SVZ>Чтобы выявить более серьезные ошибки приходится вникать в код, понимать, какую задачу этот код решает, как ее решает. А обычно каждый решает свою задачу, на выяснение, чем занимаются вокруг, времени нет. Т.е. трудозатраты на ревью получаются лишь немногим меньше, чем написание этой функциональности с нуля самостоятельно. И на такое никто время не выделяет.
"лишь немногим меньше" — в 4-6 раз примерно. Можно и быстрее ревью делать, но тогда ошибки проскакивают.
А еще можно ревью автоматизировать тулами, тогда анализ кода делается примерно в 10 раз быстрее, если код написан нормально.
SVZ>Поэтому согласен со SkyKnight, что за внутренности плагина пусть отвечает исполнитель, главное, чтобы тесты проходили.
Ну кому как...
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, kostik78, Вы писали:
K>>Если это кризис менеджер — то на мой взгляд вывод простой. Предоставить развернутый анализ текущей ситуации вышестоящемоу менеджеру и вынести предложение об увеличений срока проекта и уволнений програмиста.
_AB>Примерно так бы я и поступил будь я на его месте. Но я не программист и не менеджер. _AB>И есть в связи с этим у меня один вопрос ниже.
K>>Принимать решение в данной ситуации самому менеджеру не стоит.
_AB>Зачем нужен менеджер, если он боится принимать решения в рамках своей компетенции? _AB>Или это не его компетенция? Но тогда он скорее аудитор, а не менеджер получается?
Дело не в компетенции и не в том что боится принимать решения. Его пригласили со стороны и он может не знать всех тонкостей проекта и какие бизнес причины для него. То бишь самому менеджеру сложно оценить все аспекты и возможные последствия того или иного решения. Также проект уже в состояния "риска" — значит менеджеру стоит позаботится о своем "заднем месте". Либо получить "индульгенцию" от вышестоящего менеджемнта, либо шарить респонсибилити на принятое решение. Это как бы сделал я будучи на месте этого менеджера Но мои действия базируются на моем 6-летнем опыте управления 30+ подчиненными (4 тима) в западной компании. В России реалити бизнеса немного другие.
Здравствуйте, enji, Вы писали:
E>Наткнулся на интересное
E>Вкратце: E>
E>Есть проект, который уже пол года выполняет сторонняя ИТ-фирма подрядчик.
E>А программист Д – с нашей стороны приемщик работ, текстов и всего проекта.
E>Месяц назад они — наш программист и подрядчик поссорились.
E>Теперь программист решил всем назло, сделать всё самостоятельно с помощью одного своего помощника.
E>...
E>Позиция программиста:
E>Я же сам готов всё сделать. Это будет бесплатно и гораздо лучше, чем сделает подрядчик.
E>Нужно немедленно разорвать контракт с подрядчиком.
E>Тогда я (программист) берусь все сделать через месяц и совершенно бесплатно ( за зарплату), только ко мне никто не должен лезть и мешать.
...
E>Вопрос классический:
E>- Что делать?
Самое интересно, из-за чего "поссорились" программист и подрядчик. Они что, за разные футбольные клубы болеют? Скорее всего программисту чем-то не понравился результат работы подрядчика. Так что почему бы не заставить подрядчика сделать работу так, как это требует программист? Пригрозив разрывом контракта.
А то получается, что сначала фирма поставила программиста рулить подрядчиком, а потом в возникшем конфликте заняла сторону подрядчика. Директор кому больше доверяет — своему сотруднику или подрядчику? Если директор сам больше знает, то пусть увольняет программера и сам добивает проект.
Сейчас у фирмы два варианта: либо сказать "Я начальник — ты дурак", либо сказать "Клиент всегда прав". Чтобы принять решение, нужно определиться, кто объективно прав в возникшем конфликте, кто предлагает лучшее решение. Для этого нужно обратиться к сторонним экспертам-технарям — пусть они оценят качество решений, предлагаемых программистом и подрядчиком.
Здравствуйте, Mazay, Вы писали:
M>Сейчас у фирмы два варианта: либо сказать "Я начальник — ты дурак", либо сказать "Клиент всегда прав". Чтобы принять решение, нужно определиться, кто объективно прав в возникшем конфликте, кто предлагает лучшее решение. Для этого нужно обратиться к сторонним экспертам-технарям — пусть они оценят качество решений, предлагаемых программистом и подрядчиком.
Насколько я понял ТС и является этим сторонним экспертом-технарем (точнее уже не сторонним).
Здравствуйте, Mazay, Вы писали:
M>Самое интересно, из-за чего "поссорились" программист и подрядчик. Они что, за разные футбольные клубы болеют? Скорее всего программисту чем-то не понравился результат работы подрядчика. Так что почему бы не заставить подрядчика сделать работу так, как это требует программист? Пригрозив разрывом контракта.
M>А то получается, что сначала фирма поставила программиста рулить подрядчиком, а потом в возникшем конфликте заняла сторону подрядчика. Директор кому больше доверяет — своему сотруднику или подрядчику? Если директор сам больше знает, то пусть увольняет программера и сам добивает проект.
тут два варианта:
1) подрядчик откатил директору или каким-то другим образом является аффилированным
2) ранее мнение программиста демонстративно проигнорировали или каким-то другим образом задели его самолюбие
Возможно что оба сразу.
M>Сейчас у фирмы два варианта: либо сказать "Я начальник — ты дурак", либо сказать "Клиент всегда прав". Чтобы принять решение, нужно определиться, кто объективно прав в возникшем конфликте, кто предлагает лучшее решение. Для этого нужно обратиться к сторонним экспертам-технарям — пусть они оценят качество решений, предлагаемых программистом и подрядчиком.
В первую очередь надо думать как проект в срок сдать, а не выяснять кто прав.
Здравствуйте, Mazay, Вы писали:
M>Самое интересно, из-за чего "поссорились" программист и подрядчик. Они что, за разные футбольные клубы болеют? Скорее всего программисту чем-то не понравился результат работы подрядчика. Так что почему бы не заставить подрядчика сделать работу так, как это требует программист? Пригрозив разрывом контракта.
Если комменты почитать, то да, там примерно так и было. Конфликт этот уладили.
M>А то получается, что сначала фирма поставила программиста рулить подрядчиком, а потом в возникшем конфликте заняла сторону подрядчика. Директор кому больше доверяет — своему сотруднику или подрядчику? Если директор сам больше знает, то пусть увольняет программера и сам добивает проект.
Основная проблема с этим программером, что он рогом уперся и не хочет работать с подрядчиком, а хочет сам писать всё с нуля.
Предыдущий конфликт (в котором была вина подрядчика) улажен.
1/14/2014 8:47 PM, gandjustas пишет:
> В первую очередь надо думать как проект в срок сдать, а не выяснять кто > прав.
Вообще от в первую очередь тут надо думать о том, как прикрыть свою задницу.
1/14/2014 9:00 PM, _ABC_ пишет:
> Основная проблема с этим программером, что он рогом уперся и не хочет > работать с подрядчиком, а хочет сам писать всё с нуля. > Предыдущий конфликт (в котором была вина подрядчика) улажен.
Значит снимайте его с этого проекта — выбора все одно нет.
Тем более, если с заказчиком вопросы решены.
G>Ну то есть ты приемкой то и не занимаешься, просто передастом работаешь. G>Фактически качество кода подрядчиков контролирует только тестер.
Это некорректное заявление. Прежде, чем тестер что-то протестирует, это "что-то" должно стать явным и известным. Иными словами, чтобы тестер стал тестировать вот такой-то сценарий, этот сценарий должен быть где-то описан, зафиксирован, запротоколирован и т.п.. Это достаточно сложная и ответственная работа — выбрать с одной стороны минимальный, с другой — охватывающий все важные функциональные моменты набор. А также их приоретизировать.
В конечном итоге тестер вряд ли все это делает руками. Обычно его работа состоит в том, чтобы запрограммировать сценарий и добавить тест в набор автоматического билда.
_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% ошибки уровня "не работает и работает не
правильно". Я так понимаю, что это все учтено и отражено в той книжке?
З.Ы. Вопросы тебе, потому как ты привел этого авторитета, как
доказательство. Ты его прекрасно изучил и понимаешь все, что он написал
и поэтому сможет кратко и четко ответить.
З.З.Ы.
Пока опущу вопрос откуда у него взялись тысячи проектов, да еще и со
столь глубоким их анализом — это потом.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>И они будут правы. Тем не менее приемкой занимается тестер, а не ты. SK>Еще раз. С точки зрения тестировщика — да, с точки зрения вышестоящего начальства — нет. Обычно считается (официально) принимает тот, кто несет потом за это ответственность. Ответсвенный, конечно, может это делегировать ниже, но от этого его ответсвенность перед вышестоящим начальством не уходит ни куда.
напимню что разговор начался с того что ты бы не смог читать код для приекми. После выяснения подробностей оказалось что лично ты не занимаешься приемкой, а это делает тестер.
Если бы приемкой занимался ты, то быстро бы понял (я надеюсь) что код читать получается быстрее, чем тесты гонять. Особенно в сложных проектах, где недостаточно соотвествия функциональной спецификации.
G>>Есть план. Но это не помогает когда воссоздать внешние условия сложно. SK>У нас тестируются на данных максимально приближенных к реальным. Поэтому можно на тестах покрыть много чего. Но все, конечно, не покроешь.
Я говорю не про функциональное тестирование. Есть немало проектов где функционал составляет не более 50% качества всего решения, остальное это UX, manageability, reliability и прочие страшные слова.
G>>Потому что разработчик, может лучше качество обеспечить в случае нетривиального приложения. G>>Не факт конечно что захочет. SK>И как поможет ревью, если в системе несколько исполняемых файлов, которые между собой разными путиями коммуницируют (кто-то по TCP/IP, кто-то через файлы, кто-то через базу данных). В этом случае ревью поможет чуть менее, чем ничем. Или если в программе несколько потоков, то гонки между ними при ревью отловить почти что невозможно, ну разве что у человека в голове компилятор зашит. К тому же, как уже сказали, надо точно понимать, что происходит в коде.
Как раз гонки тестами выловить нереально, потому что race condition на машине тестера может не возникать. Кроме того, даже если тест обнаружит concurrency баг, то не сможет определить его место, так как программа упадет сильно позже, чем то место, где проблема появилась и придется читать код чтобы место найти.
Кстаи баги, связанные c race condition очень хорошо видны, они часто возникают при обращении к static полям и данным, явно передаваемым в другой поток. Таких обычно в программе немного.
SK>А чтобы понять, что написали 4 человека, весьма и весьма сложно.
Проще чем протестировать, особенно если задача не сводится реализации алгоритма\ простого интерфейса.
SK>Просто прочитать его как книжку смысла не иммет, разве что отловятся ошибки типа SK>
SK>int i = 0;
SK>for ( i = 0; i < n; i++)
SK>{
SK> ....
SK> for ( i = 5; i < m; i++ )
SK> {
SK> }
SK> ....
SK>}
SK>
А ты пробовал формальный code review проводить? Такое ощущение что нет.
SK>Но и при тестировании может показать, что в таком-то модуле при таких-то действиях выходные данные не те, которые нужны и дальше уже программисты ищут ошибку.
Все наборы выходных данных прогнать нельзя, все параметры окружения в тестах учесть нельзя.
Ты говоришь только о функциональном тестировании, которое само по себе не полностью покрывает "качество".
SK>Я, конечно, не хочу занижать твои способности, если ты правда при ревью видишь все ошибки и довольно быстро их находишь, то в твоем случае действительно может быть так и лучше делать. Я, например, слету в чужой код врубиться не смогу. Даже довольно простые функции мне надо сначала посмотреть, потом посмотреть места где она вызывается и только потом принять решение ошибка там или нет. Так что тут может только на одну функцию у меня уйти от 20 мин до 1 часа и при куче кода в пару мегов я просто никогда приемку не закончу.
Этим ты как раз подтвердаешь тезис, что не каждому программисту дано приемкой кода заниматься. Кто-то умеет быстро код читать и восстанавливать мысль автора, но таких мало, обычно программисты умеют писать быстрее, чем читать.
Навык чтения кода можно ( и ИМХО нужно) тренировать, от этого программисты становятся лучше.
Кстати пару мегов кода генерить надо около 3 месяцев. Ты же не будешь плевать в потолок все это время. Ревью имеет смысл делать в процессе. Если ты получешь результат в конце, то и вариантов как-бы нет, только и остается тестировать.
Здравствуйте, gandjustas, Вы писали:
G>А ты первоисточник прочитай, там и ссылка на оригинальное исследование, и само исследование вполне достойное. Довольно глупо отрицать его результаты
G>Вот тебе краткая выжимка — http://gandjustas.blogspot.com/2013/07/code-review-vs-testing.html
Вот возьмем, например, regressions tests. Не совсем понятно какие именно 25% тут имеются ввиду?
Поясню.
Всего в программе есть 100 ошибок (это 100%). Из них 10 ошибок это эти самые regression bugs (это 10% от всех) и 90 ошибок это ошибки из нового кода, которые никак не влияют на старый.
Т.е. получается, что при regression tests ловят только 3 ошибки или все-таки они ловят в среднем 25 ошибок?
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 1:48 PM, gandjustas пишет:
>> Вот тебе краткая выжимка — >> http://gandjustas.blogspot.com/2013/07/code-review-vs-testing.html >> >> Вообще ошибаться не страшно, страшно не признавать ошибки и называть >> всех вокруг идиотами. V>Ну тогда тебе простой вопрос. Как определялось полное количество ошибок V>в проекте?
Почитай по ссылкам.
V>Лично я не могу даже представить способа определить это?
А в чем проблема? Лезешь в трекер и считаешь кол-во ошибок. В США самые толстые проекты очень плотно обкладываются всяческими метриками и фиксируется буквально все, вплоть до ошибок компиляции. Поэтому по таким проектам есть очень хороршая статистика. Сейчас такую статистику собрать сложнее, ибо в эру стартапов код пишется почти бесконтрольно. Но есть другие исследования, которые показывают что программисты пишу примерно одинаково, независимо от инструментов и языков.
V>Т.е. пойдем от печки, что значит его циферки в процентах, надеюсь не то, V>что в известных анекдотах про проценты.
Сколько в среднем та или иная методика устраняет ошибок. По каждому проекту посчитали процентное соотношение и усреднили. Это конечно вносит искажения, но на большой выборке все стремится к матожиданию.
V>Ну и следующий вопрос — ошибка ошибке рознь, одна ошибка приводит V>программу в состояние неработоспособности или неправильной работы, а V>другая всего-лишь о том, что кнопка не тем цветом нарисована. Это к V>тому, что какие ошибки учитывать в этой оценке, а какие нет?
Традиционный подход — считать дефектами все, вплоть то ошибок компиляции. Такой подход наиболее соответствует воспринимаемому качеству.
Хотя наверное цвета кнопок не учитывались.
V>Ну и сразу еще вопрос. Даже если мы каким-то фантастическим образом V>смогли найти все ошибки в проекте. Но в одном 99% ошибки уровня "не тот V>цвет", а в другом 99% ошибки уровня "не работает и работает не V>правильно". Я так понимаю, что это все учтено и отражено в той книжке?
См выше.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>А ты первоисточник прочитай, там и ссылка на оригинальное исследование, и само исследование вполне достойное. Довольно глупо отрицать его результаты
G>>Вот тебе краткая выжимка — http://gandjustas.blogspot.com/2013/07/code-review-vs-testing.html
SK>Вот возьмем, например, regressions tests. Не совсем понятно какие именно 25% тут имеются ввиду? SK>Поясню. SK>Всего в программе есть 100 ошибок (это 100%). Из них 10 ошибок это эти самые regression bugs (это 10% от всех) и 90 ошибок это ошибки из нового кода, которые никак не влияют на старый. SK>Т.е. получается, что при regression tests ловят только 3 ошибки или все-таки они ловят в среднем 25 ошибок?
Распределения по типам ошибок нет, в твоем случае это 25 ошибок будет.
Кстати очень похоже на правду. Если писать тесты после кода для контроля чтобы не поломалось, то потом при доработках примерно четверть ошибок отловит.
Здравствуйте, gandjustas, Вы писали:
G>напимню что разговор начался с того что ты бы не смог читать код для приекми. После выяснения подробностей оказалось что лично ты не занимаешься приемкой, а это делает тестер. G>Если бы приемкой занимался ты, то быстро бы понял (я надеюсь) что код читать получается быстрее, чем тесты гонять. Особенно в сложных проектах, где недостаточно соотвествия функциональной спецификации.
Все-таки повторять мне опять придется. Принимаю работу подрядчика я. Я не гений, читать быстро чужой код не умею. В своем проекте, я конечно, знаю о чем идет речь и тут-то идет у меня все быстрее.
G>Я говорю не про функциональное тестирование. Есть немало проектов где функционал составляет не более 50% качества всего решения, остальное это UX, manageability, reliability и прочие страшные слова.
Reliability покрывается такими же функциональными тестами без проблем. Manageability мне неизвестна.
G>Как раз гонки тестами выловить нереально, потому что race condition на машине тестера может не возникать. Кроме того, даже если тест обнаружит concurrency баг, то не сможет определить его место, так как программа упадет сильно позже, чем то место, где проблема появилась и придется читать код чтобы место найти.
Может не возникать, а может и возникать, поэтому и тестируется на максимально больших и разных наборах данных. У нас их дофига. От разных клиентов и с разными параметрами.
G>Кстаи баги, связанные c race condition очень хорошо видны, они часто возникают при обращении к static полям и данным, явно передаваемым в другой поток. Таких обычно в программе немного.
Мне не нужно точное место этого бага. Мне достаточно, что тестировщик найдет ошибки при тестировании, а что там внутри (race conditions или if (a = 1) .... ) меня уже не касается. Я отдаю набор данных подрядчику, шаги как возпроизхвести баг и все. Дальше там он уже сам разбирается читать ему код или нет.
SK>>А чтобы понять, что написали 4 человека, весьма и весьма сложно. G>Проще чем протестировать, особенно если задача не сводится реализации алгоритма\ простого интерфейса.
Кому как, мне — нет.
G>А ты пробовал формальный code review проводить? Такое ощущение что нет.
Внутри команды всегда.
SK>>Но и при тестировании может показать, что в таком-то модуле при таких-то действиях выходные данные не те, которые нужны и дальше уже программисты ищут ошибку. G>Все наборы выходных данных прогнать нельзя, все параметры окружения в тестах учесть нельзя.
Что тут подразумевается под параметрами окружения? Фаза луны? У клиента все настраивается один раз, параметры системы меняются чуть реже, чем никогда. Систему учета товара на складе каждый день параметрироваь не будешь, а так же сервера для БД или еще чего-то раз в год менять тоже не будешь.
G>Ты говоришь только о функциональном тестировании, которое само по себе не полностью покрывает "качество".
Для этих плагинов от подрядчиков нам достаточно только функционаьного тестирования. Потому что это ни что иное как функция для нас. Мы вызвали ее с параметром a, должен получиться результат a/2, если получился a/3, значит что-то там не то.
G>Этим ты как раз подтвердаешь тезис, что не каждому программисту дано приемкой кода заниматься. Кто-то умеет быстро код читать и восстанавливать мысль автора, но таких мало, обычно программисты умеют писать быстрее, чем читать. G>Навык чтения кода можно ( и ИМХО нужно) тренировать, от этого программисты становятся лучше.
Я не занимаю приемкой кода, я делаю приемку модуля, а точнее приемку функциональности этого модуля, как он там внутри реализован мне абсолютно фиолетово, мне важно, чтобы при определенном наборе входных данных я получал нужный мне результат за нужный мне отрезок времени. Если например при объеме данных X мне нужен результат через время t, а он приходит через время t*2, то я говорю подрядчику, что "модуль не принят, не удовлетворяет спецификации. Работай дальше". И он работает.
G>Кстати пару мегов кода генерить надо около 3 месяцев. Ты же не будешь плевать в потолок все это время. Ревью имеет смысл делать в процессе. Если ты получешь результат в конце, то и вариантов как-бы нет, только и остается тестировать.
Кто бы мог подумать, что ревью надо делать в процессе. Только вот результат я получаю в конце. По крайней мере когда уже есть первая pre-alpha версия, которая хотя бы чего-то может, просто чтобы определить движется ли подрядчик в правильном направлении. И даже уже эту pre-alpha не отревьюешь за пару дней.
SVZ>>По моему опыту ревью ловит только стилистические отклонения от Code Standard и потенциальные ошибки, которые просто бросаются в глаза (типа неуместного использования new/delete в С++ коде). G>Это значит что ты код смотрел, а не читал.
Читал это высказывание. Смотрел в картинку в твоей подписи. Вспоминал анекдот про "либо крестик, либо трусы". Много думал.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>напимню что разговор начался с того что ты бы не смог читать код для приекми. После выяснения подробностей оказалось что лично ты не занимаешься приемкой, а это делает тестер. G>>Если бы приемкой занимался ты, то быстро бы понял (я надеюсь) что код читать получается быстрее, чем тесты гонять. Особенно в сложных проектах, где недостаточно соотвествия функциональной спецификации. SK>Все-таки повторять мне опять придется. Принимаю работу подрядчика я. Я не гений, читать быстро чужой код не умею. В своем проекте, я конечно, знаю о чем идет речь и тут-то идет у меня все быстрее.
Руками делает тестер, а не ты.
G>>Я говорю не про функциональное тестирование. Есть немало проектов где функционал составляет не более 50% качества всего решения, остальное это UX, manageability, reliability и прочие страшные слова. SK>Reliability покрывается такими же функциональными тестами без проблем. Manageability мне неизвестна.
Интересно...
Как проверить что код не развалится и не положит все остальное при удалении сервера из фермы? Или при изменении доступов?
G>>Кстаи баги, связанные c race condition очень хорошо видны, они часто возникают при обращении к static полям и данным, явно передаваемым в другой поток. Таких обычно в программе немного. SK>Мне не нужно точное место этого бага. Мне достаточно, что тестировщик найдет ошибки при тестировании, а что там внутри (race conditions или if (a = 1) .... ) меня уже не касается. Я отдаю набор данных подрядчику, шаги как возпроизхвести баг и все. Дальше там он уже сам разбирается читать ему код или нет.
У тебя очень хорошие подрядчики. Обычно бывает так:
1) Подрядчики не находят race condition потому что тестирует один пользователь
2) UAT не находят race condition потому что тестирует один пользователь
3) В продакшене возникает баг почти сразу
4) Тестеры не могут воспроизвести
5) Инженер долго ковыряется на продакшене, смотрит логи, в конце-концов понимает что бага в race condition
6) Тестеры делают новый тест на race condition, выясняют что бага есть
6) Начинаешь пинать подрядчиков, они мамой клянутся что все работает (у них теста на race condition нет)
7) Ругаешься с ними, они долго тупят и не понимают как найти место где возникает race condition, отправляют тебе пару нерабочих версий
8) Наконец происходит озарение и подрядчики чинят баг.
По времени 1-8 занимает две недели и более. Если читать код на шаге 1, то можно количество таких случаев сократить на 60%, по времени можно выйграть на порядок, по трудозатратам в 10 раз.
И это кстати реальная история.
SK>>>А чтобы понять, что написали 4 человека, весьма и весьма сложно. G>>Проще чем протестировать, особенно если задача не сводится реализации алгоритма\ простого интерфейса. SK>Кому как, мне — нет.
Я уже понял что для тебя сложно код читать, но есть статистика, которая говорил что формальные review эффективнее тестов.
G>>А ты пробовал формальный code review проводить? Такое ощущение что нет. SK>Внутри команды всегда.
Помогает?
SK>>>Но и при тестировании может показать, что в таком-то модуле при таких-то действиях выходные данные не те, которые нужны и дальше уже программисты ищут ошибку. G>>Все наборы выходных данных прогнать нельзя, все параметры окружения в тестах учесть нельзя. SK>Что тут подразумевается под параметрами окружения? Фаза луны? У клиента все настраивается один раз, параметры системы меняются чуть реже, чем никогда. Систему учета товара на складе каждый день параметрироваь не будешь, а так же сервера для БД или еще чего-то раз в год менять тоже не будешь.
Ключевое выделил. Если окружение полностью котролируемо, то проблем таких почти нет. А когда могут пооменяться: учетки, права, код может переехать на другой сервер без твоего ведома, серваки могут добавляться и удаляться, могут ставиться другие приложения, которые что-то делают, админы могут менять логику итд.
G>>Ты говоришь только о функциональном тестировании, которое само по себе не полностью покрывает "качество". SK>Для этих плагинов от подрядчиков нам достаточно только функционаьного тестирования. Потому что это ни что иное как функция для нас. Мы вызвали ее с параметром a, должен получиться результат a/2, если получился a/3, значит что-то там не то.
Значит ничего сложного подрядчики не делают если таких тестов достаточно.
G>>Этим ты как раз подтвердаешь тезис, что не каждому программисту дано приемкой кода заниматься. Кто-то умеет быстро код читать и восстанавливать мысль автора, но таких мало, обычно программисты умеют писать быстрее, чем читать. G>>Навык чтения кода можно ( и ИМХО нужно) тренировать, от этого программисты становятся лучше. SK>Я не занимаю приемкой кода, я делаю приемку модуля, а точнее приемку функциональности этого модуля, как он там внутри реализован мне абсолютно фиолетово, мне важно, чтобы при определенном наборе входных данных я получал нужный мне результат за нужный мне отрезок времени. Если например при объеме данных X мне нужен результат через время t, а он приходит через время t*2, то я говорю подрядчику, что "модуль не принят, не удовлетворяет спецификации. Работай дальше". И он работает.
Я по моему писал уже, что далеко не всегда достаточно удовлетворения только функциональных требований. Как минимум код еще поддерживать надо. И это должно быть дешевле, чем код писать. Как это тестами покроешь?
G>>Кстати пару мегов кода генерить надо около 3 месяцев. Ты же не будешь плевать в потолок все это время. Ревью имеет смысл делать в процессе. Если ты получешь результат в конце, то и вариантов как-бы нет, только и остается тестировать. SK>Кто бы мог подумать, что ревью надо делать в процессе. Только вот результат я получаю в конце. По крайней мере когда уже есть первая pre-alpha версия, которая хотя бы чего-то может, просто чтобы определить движется ли подрядчик в правильном направлении. И даже уже эту pre-alpha не отревьюешь за пару дней.
Мне кажется что тебе очень повезло с подрядчиками если при таком подходе проблем нет. Или с проектом.
1/15/2014 2:35 PM, gandjustas пишет:
> Почитай по ссылкам.
ЧТД.
> V>Лично я не могу даже представить способа определить это? > А в чем проблема? Лезешь в трекер и считаешь кол-во ошибок.
Упс. В трекере может быть как 100% ошибок, так и 3% от всех возможных
ошибок, которые просто не были обнаружены. Уже здесь левое предположение
о том, что в трекере 100% ошибок.
> Сколько в среднем та или иная методика устраняет ошибок. По каждому > проекту посчитали процентное соотношение и усреднили. Это конечно вносит > искажения, но на большой выборке все стремится к матожиданию.
Жесть. С такими подходами я тебе любые циферки по любым исходным данным
нарисую.
> Традиционный подход — считать дефектами все, вплоть то ошибок > компиляции.
Еще круче.
> См выше.
Да я понял. Очередная туфта ни о чем, точнее о том, что мужик умница
написал книжек несколько и заработал на их продаже денег.
З.Ы. Или это ты настолько "хорошо" Макконела понял, или он еще тот
разводящий.
З.З.Ы. А по сути куча ни на чем не основанных допущении и на основе этих
допущений некие глобальные выводы.
Здравствуйте, gandjustas, Вы писали:
G>>>Я говорю не про функциональное тестирование. Есть немало проектов где функционал составляет не более 50% качества всего решения, остальное это UX, manageability, reliability и прочие страшные слова. SK>>Reliability покрывается такими же функциональными тестами без проблем. Manageability мне неизвестна. G>Интересно... G>Как проверить что код не развалится и не положит все остальное при удалении сервера из фермы? Или при изменении доступов?
Сервера не "исчезают" просто так, к тому же в таких крупных конторах как наши клиенты.
Изменение доступа тоже просто так не происходит, чтобы там на продакшене что-то поменять админ перед этим должен получить кучу разрешений.
G>По времени 1-8 занимает две недели и более. Если читать код на шаге 1, то можно количество таких случаев сократить на 60%, по времени можно выйграть на порядок, по трудозатратам в 10 раз. G>И это кстати реальная история.
Ну да, так тоже случается. Не без этого. Но случается это довольно редко, поэтому трудозатраты на кодревью кода подрятчика никак не окупаются.
G>Я уже понял что для тебя сложно код читать, но есть статистика, которая говорил что формальные review эффективнее тестов.
Я не знаю на основе чего собрана эта статистика, я вообще статистикам не особо доверяю. Там можно нарисовать все что угодно.
Вот я возьму создам свою статистику где напишу, что собирались данные по 10 тыс проектов и результат — тесты эффективнее ревью. И это никак не опровергнешь, потому что все данные по всем проектом нигде не выложены в открытом доступе.
G>Помогает?
Конечно.
G>Ключевое выделил. Если окружение полностью котролируемо, то проблем таких почти нет. А когда могут пооменяться: учетки, права, код может переехать на другой сервер без твоего ведома, серваки могут добавляться и удаляться, могут ставиться другие приложения, которые что-то делают, админы могут менять логику итд.
Если админ просто так меняет логику на продакшене и в результате этого что-то происходит с системой, то он несет за это ответсвенность. Тоже самое, если вдруг удалить исполняемый файл (или модуль) и потом удивляться, что что-то не так работает.
G>Значит ничего сложного подрядчики не делают если таких тестов достаточно.
С нашей точки зрения нет. Для нас они пишут одну большую функцию, а реализована ли она сложно или просто я не знаю.
G>Я по моему писал уже, что далеко не всегда достаточно удовлетворения только функциональных требований. Как минимум код еще поддерживать надо. И это должно быть дешевле, чем код писать. Как это тестами покроешь?
Код поддерживает подрядчик. Так что это в его интересах написать его хорошо.
G>Мне кажется что тебе очень повезло с подрядчиками если при таком подходе проблем нет. Или с проектом.
Всякие бывают. Вот был проект с Казино в Австрии. Была там одна фирма, которая поставляла туда видеорегистраторы. У них была API для доступа к видео, архиву и прочему. Так вот проблема возникала только у клиента. В итоге после 2х или 3х месяцев борьбы с этими поставщиками выяснилось, что проблема возникала на компьютерах, где стояли 4х ядерные процы. На 2х ядерных было еще все нештяг.
Предупреждая твой вопрос о ревью скажу, что доступа к коду этого производителя у нас не было, да и я бы все равно в него бы смотреть не стал. Приложение, которое по сети запрашивает видо с регистратора, декодирует mpeg4 и показывает Live-Video или архив не такое уж и тривиальное, чтобы там быстро найти ошибку такую ошибку.
Да и вообще в Европе не принято отдавать код. Если хочешь его позырить — покупай всю контору целиком. И не важно разовая эта работа или же коробочный продукт.
Здравствуйте, gandjustas, Вы писали:
G>У тебя очень хорошие подрядчики. Обычно бывает так: G>1) Подрядчики не находят race condition потому что тестирует один пользователь G>2) UAT не находят race condition потому что тестирует один пользователь G>3) В продакшене возникает баг почти сразу G>4) Тестеры не могут воспроизвести G>5) Инженер долго ковыряется на продакшене, смотрит логи, в конце-концов понимает что бага в race condition G>6) Тестеры делают новый тест на race condition, выясняют что бага есть G>6) Начинаешь пинать подрядчиков, они мамой клянутся что все работает (у них теста на race condition нет) G>7) Ругаешься с ними, они долго тупят и не понимают как найти место где возникает race condition, отправляют тебе пару нерабочих версий G>8) Наконец происходит озарение и подрядчики чинят баг.
Вообще-то это называется: "бардак обыкновенный". Но мне больше всего понравилось про "мамой клянутся".
Ну и совет. Послушай оппонента SD и постарайся хоть чуть приблизить вашу работу к его.
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 2:35 PM, gandjustas пишет:
>> Почитай по ссылкам. V>ЧТД.
Значит не читал
>> V>Лично я не могу даже представить способа определить это? >> А в чем проблема? Лезешь в трекер и считаешь кол-во ошибок. V>Упс. В трекере может быть как 100% ошибок, так и 3% от всех возможных V>ошибок, которые просто не были обнаружены. Уже здесь левое предположение V>о том, что в трекере 100% ошибок.
Думаешь люди, которые проводили анализ об этом не знали? Обычно анализ проводится на завершенных проектах.
Кстати в их понятии "завершенный" означает что не просто акты подписали.
>> Сколько в среднем та или иная методика устраняет ошибок. По каждому >> проекту посчитали процентное соотношение и усреднили. Это конечно вносит >> искажения, но на большой выборке все стремится к матожиданию. V>Жесть. С такими подходами я тебе любые циферки по любым исходным данным V>нарисую.
Нарисуй, в чем проблема?
>> См выше. V>Да я понял. Очередная туфта ни о чем, точнее о том, что мужик умница V>написал книжек несколько и заработал на их продаже денег.
О как-бы на исследования опирается, сам ничего не придумал. Исследования гуглятся.
V>З.Ы. Или это ты настолько "хорошо" Макконела понял, или он еще тот V>разводящий. V>З.З.Ы. А по сути куча ни на чем не основанных допущении и на основе этих V>допущений некие глобальные выводы.
См. то что я написал выше.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>По времени 1-8 занимает две недели и более. Если читать код на шаге 1, то можно количество таких случаев сократить на 60%, по времени можно выйграть на порядок, по трудозатратам в 10 раз. G>>И это кстати реальная история. SK>Ну да, так тоже случается. Не без этого. Но случается это довольно редко, поэтому трудозатраты на кодревью кода подрятчика никак не окупаются.
А трудозатраты на тестирование тогда как окупаются?
G>>Я уже понял что для тебя сложно код читать, но есть статистика, которая говорил что формальные review эффективнее тестов. SK>Я не знаю на основе чего собрана эта статистика, я вообще статистикам не особо доверяю. Там можно нарисовать все что угодно. SK>Вот я возьму создам свою статистику где напишу, что собирались данные по 10 тыс проектов и результат — тесты эффективнее ревью. И это никак не опровергнешь, потому что все данные по всем проектом нигде не выложены в открытом доступе.
Ок, создай.
G>>Ключевое выделил. Если окружение полностью котролируемо, то проблем таких почти нет. А когда могут пооменяться: учетки, права, код может переехать на другой сервер без твоего ведома, серваки могут добавляться и удаляться, могут ставиться другие приложения, которые что-то делают, админы могут менять логику итд. SK>Если админ просто так меняет логику на продакшене и в результате этого что-то происходит с системой, то он несет за это ответсвенность. Тоже самое, если вдруг удалить исполняемый файл (или модуль) и потом удивляться, что что-то не так работает.
Админ делает вполне законные, с точки зрения платформы, действия. А решение на рассчитано что такие действия будут производиться.
G>>Я по моему писал уже, что далеко не всегда достаточно удовлетворения только функциональных требований. Как минимум код еще поддерживать надо. И это должно быть дешевле, чем код писать. Как это тестами покроешь? SK>Код поддерживает подрядчик. Так что это в его интересах написать его хорошо.
Он же за это деньги получает, ему выгодно побольше на поддержке сшибать.
SK>Да и вообще в Европе не принято отдавать код. Если хочешь его позырить — покупай всю контору целиком. И не важно разовая эта работа или же коробочный продукт.
Очень повезло. Все друг другу доверяют и не нае... обманывают.
Здравствуйте, Vzhyk, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>У тебя очень хорошие подрядчики. Обычно бывает так: G>>1) Подрядчики не находят race condition потому что тестирует один пользователь G>>2) UAT не находят race condition потому что тестирует один пользователь G>>3) В продакшене возникает баг почти сразу G>>4) Тестеры не могут воспроизвести G>>5) Инженер долго ковыряется на продакшене, смотрит логи, в конце-концов понимает что бага в race condition G>>6) Тестеры делают новый тест на race condition, выясняют что бага есть G>>6) Начинаешь пинать подрядчиков, они мамой клянутся что все работает (у них теста на race condition нет) G>>7) Ругаешься с ними, они долго тупят и не понимают как найти место где возникает race condition, отправляют тебе пару нерабочих версий G>>8) Наконец происходит озарение и подрядчики чинят баг. V>Вообще-то это называется: "бардак обыкновенный". Но мне больше всего понравилось про "мамой клянутся". V>Ну и совет. Послушай оппонента SD и постарайся хоть чуть приблизить вашу работу к его.
В России и странах СНГ так чуть менее, чем везде. Почти все конторы, которые зарабатывают аутсорсингом кодирования жестко экономят на разработчиках и на контроле качества. А эффективные менеджеры прекрасно знают формулу "у нас все работает — проблема на вашей стороне".
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, SkyKnight, Вы писали:
SK>>Здравствуйте, gandjustas, Вы писали:
G>>>По времени 1-8 занимает две недели и более. Если читать код на шаге 1, то можно количество таких случаев сократить на 60%, по времени можно выйграть на порядок, по трудозатратам в 10 раз. G>>>И это кстати реальная история. SK>>Ну да, так тоже случается. Не без этого. Но случается это довольно редко, поэтому трудозатраты на кодревью кода подрятчика никак не окупаются. G>А трудозатраты на тестирование тогда как окупаются?
Трудозатраты на тестирование внесены в смету проекта. Т.е. из опыта мы уже примерно знаем, что на тестирование модуля надо будет 50 часов. Трудозатраты на ревью в смету проекта я внести явно не могу, т.е. надо будет выдумывать какую-нибудь статью расходов.
G>Ок, создай.
Да ради Бога.
Вот в течение 10 лет собирал статистику по проектам. В итоге была собрана статистика по 10 тыс проектов. Статистика показала, что тестирование в 4 раза эффективнее ревью.
G>Админ делает вполне законные, с точки зрения платформы, действия. А решение на рассчитано что такие действия будут производиться.
На продакшене любые действия админа без разрешения вышестоящих людей являются незаконными. Потому что если в результате его дейтствий случится что-то с операционной системой ему настанет такой кирдык, что засовывание ведра в задницу покажется райским наслаждением по сравнению с этим кирдыком.
G>Он же за это деньги получает, ему выгодно побольше на поддержке сшибать.
Первые 2 года после покупки или приемки баги фиксятся бесплатно. Гарантия. Далее за кажый баг срубается деньга в зависимости от наглости подрядчика. А ты уже решаешь хочешь ты его пофиксенным или нет.
Внесение новых фич оговаривается и оплачивается отдельно. В любом случае, если я заказываю работу на стороне (модуль), то в зависимости от внутренних ресурсов потом решаю, переносить дальнейшее развитие этого модуля к себе или оставлять там снаружи. Зачастую получается дешевле оставить разработку и поддержку на всегда внешей конторе. Если же ясно, что модуль всегда останется "у них", то и исходники мне нафиг не нужны.
Если же еще в самом начале ясно, что модуль потом перейдет в нашу контору на дальнейшее развитие, то понятно, что и исходники надо будет забирать, в этом случае да, подписывается такой контракт, что исходники передаются полногстью нам, включая полную документацию и прочее, прочее. Такие контракты обычно стоят дороже, потому что подрядчику надо еще тратить время на написание очень подробной документации.
G>Очень повезло. Все друг другу доверяют и не нае... обманывают.
А зачем обманывать?
1/15/2014 4:26 PM, gandjustas пишет:
> В России и странах СНГ так чуть менее, чем везде. Почти все конторы, > которые зарабатывают аутсорсингом кодирования жестко экономят на > разработчиках и на контроле качества. А эффективные менеджеры прекрасно > знают формулу "у нас все работает — проблема на вашей стороне".
Вот об этом тебе уже не раз намекнули, а ты еще и макконела к этому
приплетаешь, причем еще и не поняв толком того, что он писал. А SK пишет
о конторах с нормальными методами работы.
Про тут часто и говорить стыдно про организацию разработки и приемки, в
подавляющем большинстве случаев карго-культ с агилей, а в реальности "у
меня все работает", а директора уже новый поршекаены купили и давно все
приняли и сдали.
Да, продуктовые местные конторы часто еще хуже аутсорсинговых,
аутсорсеров еще западные заказчики могут и наказать, а продуктовые в
подавляющем большинстве на госзаказах живут.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, SkyKnight, Вы писали:
SK>>>Здравствуйте, gandjustas, Вы писали:
G>>>>По времени 1-8 занимает две недели и более. Если читать код на шаге 1, то можно количество таких случаев сократить на 60%, по времени можно выйграть на порядок, по трудозатратам в 10 раз. G>>>>И это кстати реальная история. SK>>>Ну да, так тоже случается. Не без этого. Но случается это довольно редко, поэтому трудозатраты на кодревью кода подрятчика никак не окупаются. G>>А трудозатраты на тестирование тогда как окупаются? SK>Трудозатраты на тестирование внесены в смету проекта. Т.е. из опыта мы уже примерно знаем, что на тестирование модуля надо будет 50 часов. Трудозатраты на ревью в смету проекта я внести явно не могу, т.е. надо будет выдумывать какую-нибудь статью расходов.
То есть вопрос только в том как назвать позиции в смете, а в остальном ревью таки выгоднее?
G>>Ок, создай. SK>Да ради Бога. SK>Вот в течение 10 лет собирал статистику по проектам. В итоге была собрана статистика по 10 тыс проектов. Статистика показала, что тестирование в 4 раза эффективнее ревью.
У меня ровно наоборот, а еще и исследования есть, которые подтверждают мою точку зрения.
G>>Админ делает вполне законные, с точки зрения платформы, действия. А решение на рассчитано что такие действия будут производиться. SK>На продакшене любые действия админа без разрешения вышестоящих людей являются незаконными. Потому что если в результате его дейтствий случится что-то с операционной системой ему настанет такой кирдык, что засовывание ведра в задницу покажется райским наслаждением по сравнению с этим кирдыком.
Читай выделенное.
G>>Он же за это деньги получает, ему выгодно побольше на поддержке сшибать. SK>Первые 2 года после покупки или приемки баги фиксятся бесплатно. Гарантия.
а сколько вы подрядчикам за такое платите?
G>>Очень повезло. Все друг другу доверяют и не нае... обманывают. SK>А зачем обманывать?
Философский вопрос. Я не знаю ответа на него, знаю лишь что в России везде так.
Неочень честная конкуренция построенная на ассиметричности информации.
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 4:26 PM, gandjustas пишет:
>> В России и странах СНГ так чуть менее, чем везде. Почти все конторы, >> которые зарабатывают аутсорсингом кодирования жестко экономят на >> разработчиках и на контроле качества. А эффективные менеджеры прекрасно >> знают формулу "у нас все работает — проблема на вашей стороне". V>Вот об этом тебе уже не раз намекнули, а ты еще и макконела к этому V>приплетаешь, причем еще и не поняв толком того, что он писал. А SK пишет V>о конторах с нормальными методами работы.
Он пишет о европе, а я о России. Там подрядчики сдают код с плотностью ошибок в 10 раз меньше, а заказчики платят в 2 раза больше за час работы.
Тем не менее на defect removal rate это никак не влияет, просто при такой разнице в качестве работы эта разница в defect removal rate становится незначительной.
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 4:26 PM, gandjustas пишет:
>> В России и странах СНГ так чуть менее, чем везде. Почти все конторы, >> которые зарабатывают аутсорсингом кодирования жестко экономят на >> разработчиках и на контроле качества. А эффективные менеджеры прекрасно >> знают формулу "у нас все работает — проблема на вашей стороне". V>Вот об этом тебе уже не раз намекнули, а ты еще и макконела к этому V>приплетаешь, причем еще и не поняв толком того, что он писал. А SK пишет V>о конторах с нормальными методами работы.
Ну и основной фактор у SK — код не передают, без него review не сделаешь, так что разговор ни о чем.
Здравствуйте, SkyKnight, Вы писали:
SK>Первые 2 года после покупки или приемки баги фиксятся бесплатно. Гарантия. Далее за кажый баг срубается деньга в зависимости от наглости подрядчика. А ты уже решаешь хочешь ты его пофиксенным или нет. SK>Внесение новых фич оговаривается и оплачивается отдельно. В любом случае, если я заказываю работу на стороне (модуль), то в зависимости от внутренних ресурсов потом решаю, переносить дальнейшее развитие этого модуля к себе или оставлять там снаружи. Зачастую получается дешевле оставить разработку и поддержку на всегда внешей конторе. Если же ясно, что модуль всегда останется "у них", то и исходники мне нафиг не нужны. SK>Если же еще в самом начале ясно, что модуль потом перейдет в нашу контору на дальнейшее развитие, то понятно, что и исходники надо будет забирать, в этом случае да, подписывается такой контракт, что исходники передаются полногстью нам, включая полную документацию и прочее, прочее. Такие контракты обычно стоят дороже, потому что подрядчику надо еще тратить время на написание очень подробной документации.
Блин, круто. Неужели в мире где-то так организована работа?
Я в восхищении.
Я помню французский RECIF, немецкий АТОТЕСН — бардак был близкий к местному здесь. Про аустрсорсеров наших и не говорю, втюхать заказчику фигню и забить. Говоришь начальнику можно на 3 часа говно, типа работающее, или за 3-5 дней качественно и правильно, начальник говорит за 3 часа.
1/15/2014 4:56 PM, gandjustas пишет:
> А ты где работаешь, в Европе ли в России?
В РБ и РФ и прекрасно знаю наш местный бардак и дичающую любовь всех
кинуть всех остальных вокруг.
А да, если бы я работал в Европе, то меня бы здесь на кывте не было бы —
это здесь я использую данный форум для психотерапии.
Здравствуйте, gandjustas, Вы писали:
SK>>Трудозатраты на тестирование внесены в смету проекта. Т.е. из опыта мы уже примерно знаем, что на тестирование модуля надо будет 50 часов. Трудозатраты на ревью в смету проекта я внести явно не могу, т.е. надо будет выдумывать какую-нибудь статью расходов. G>То есть вопрос только в том как назвать позиции в смете, а в остальном ревью таки выгоднее?
Я не говорил, что выгоднее. Для меня это получается гораздо заморочнее. Пример я приводил по поводу производителя видеорегистраторов. Даже если бы в том случае у меня был бы код, квалифицированное ревью я бы провести не смог, потому что знаний в этой предметной области у меня нет. Это тоже самое, как проводить осмотр машины, если совершенно не разбираешься что и как там работает.
G>У меня ровно наоборот, а еще и исследования есть, которые подтверждают мою точку зрения.
Исследования человека, которого не все еще и знают. И почему ему можно доверять, потому что он 100 книжек написал?
G>>>Админ делает вполне законные, с точки зрения платформы, действия. А решение на рассчитано что такие действия будут производиться. SK>>На продакшене любые действия админа без разрешения вышестоящих людей являются незаконными. Потому что если в результате его дейтствий случится что-то с операционной системой ему настанет такой кирдык, что засовывание ведра в задницу покажется райским наслаждением по сравнению с этим кирдыком. G>Читай выделенное.
И что? Разница между "вполне законные" и "разрешенные" огромна.
G>>>Он же за это деньги получает, ему выгодно побольше на поддержке сшибать. SK>>Первые 2 года после покупки или приемки баги фиксятся бесплатно. Гарантия. G>а сколько вы подрядчикам за такое платите?
Когда как. В зависимости от договора. Иногда почасовая оплата, иногда полностью за модуль. Второе, обычно, дороже, потому что ему надо включать тогда в цену еще и риски. Естественно, что если мы выставляем счет клиенту 129 евро в час, то подрядчик при почасовой оплате делает нам дешевле чем 129 евро, иначе смысла почти нет, разве что, когда у нас явно не хватает ресурсов, а проект стратегически важный для начальства.
G>>>Очень повезло. Все друг другу доверяют и не нае... обманывают. SK>>А зачем обманывать? G>Философский вопрос. Я не знаю ответа на него, знаю лишь что в России везде так.
Вот и возвращаемся к тому, что при нормальных отношениях, которые строятся не на обмане, приемку можно проводить почти что формально. Вообще зачастую тут строится на доверии. Вот у нас заказчик официально принял проект, с условием, что до конца февраля мы поправим все баги, которые были на момент сдачи. Т.е. официально бумажка у нас есть, деньги уплачены, а так как я не хочу потерять доверие заказчика, то баги будут пофикшены в срок.
Здравствуйте, gandjustas, Вы писали:
G>>>Админ делает вполне законные, с точки зрения платформы, действия. А решение на рассчитано что такие действия будут производиться. G>Читай выделенное.
На платформу насрать, что она считает "законным", а что нет. Закон тут — начальник админа. И если админ что-то сделает с продакшном корректное с точки зрения платформы, но не согласованное с руководством, то мехом внутрь его выверут процентов в 90 контор.
Здравствуйте, gandjustas, Вы писали:
G>Он пишет о европе, а я о России. Там подрядчики сдают код с плотностью ошибок в 10 раз меньше, а заказчики платят в 2 раза больше за час работы.
Я, к сожалению, не знаю как в Росии, но как я уже говорил, если подрядчик делает ошибки, которые даже сразу не обнаруживаются, то следующие 2 года по гарантии он фиксит их для нас бесплатно.
Скажем так, допустим они при разработке в архитектуре накосячили, что потом вылазит баг, который без рефакторинга архитектуры ну никак не пофиксишь, что, например, влечет за собой перекодивание 50% исходников.
Это никого не волнует и подрядчик делает это все за свой счет. Отсюда и вытекает, что ему самому выгодно еще на стадии разработки все отловить и продумать.
1/15/2014 5:12 PM, SkyKnight пишет:
> Я не говорил, что выгоднее. Для меня это получается гораздо заморочнее. > Пример я приводил по поводу производителя видеорегистраторов. Даже если > бы в том случае у меня был бы код, квалифицированное ревью я бы провести > не смог, потому что знаний в этой предметной области у меня нет.
Чтобы провести квалифицированное ревью тебе понадобилось бы количество
программистов сравнимое с количеством писавших продукт и времени
сравнимого с разработкой того продукта. А смысл сего действа каков?
Здравствуйте, Vzhyk, Вы писали:
V>Здравствуйте, SkyKnight, Вы писали:
SK>>Первые 2 года после покупки или приемки баги фиксятся бесплатно. Гарантия. Далее за кажый баг срубается деньга в зависимости от наглости подрядчика. А ты уже решаешь хочешь ты его пофиксенным или нет. SK>>Внесение новых фич оговаривается и оплачивается отдельно. В любом случае, если я заказываю работу на стороне (модуль), то в зависимости от внутренних ресурсов потом решаю, переносить дальнейшее развитие этого модуля к себе или оставлять там снаружи. Зачастую получается дешевле оставить разработку и поддержку на всегда внешей конторе. Если же ясно, что модуль всегда останется "у них", то и исходники мне нафиг не нужны. SK>>Если же еще в самом начале ясно, что модуль потом перейдет в нашу контору на дальнейшее развитие, то понятно, что и исходники надо будет забирать, в этом случае да, подписывается такой контракт, что исходники передаются полногстью нам, включая полную документацию и прочее, прочее. Такие контракты обычно стоят дороже, потому что подрядчику надо еще тратить время на написание очень подробной документации. V>Блин, круто. Неужели в мире где-то так организована работа? V>Я в восхищении. V>Я помню французский RECIF, немецкий АТОТЕСН — бардак был близкий к местному здесь. Про аустрсорсеров наших и не говорю, втюхать заказчику фигню и забить. Говоришь начальнику можно на 3 часа говно, типа работающее, или за 3-5 дней качественно и правильно, начальник говорит за 3 часа.
Ну как сказать, в предыдущей конторе был бардак еще тот. Что в коде, что в организации работы и с моей стороны тоже Бардак у меня был в том числе из-за того, что слишком много обязанностей на мне было и на все времени не хватало.
Иногда действительтно приходилось делать поделки, которые хотя бы на время тушили бы "пожар", но потом эти поделки оставались жить на всегда и зачастую получали развитие, превращаясь в полный и почти не поддерживаемый кал.
1/15/2014 5:17 PM, SkyKnight пишет:
> Это никого не волнует и подрядчик делает это все за свой счет.
Ну так он может сказать "ну не шмогла я", дайте еще месяц, а затем еще и
еще. И вы влетаете: переход на другого исполнителя уже будет очень дорог
и потеря времени и вынуждены идти навстречу этому.
Понятно, что через еще несколько лет вы откажетесь от этого исполнителя,
но несколько он вас будет доить. Я такое много раз наблюдал.
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 5:17 PM, SkyKnight пишет:
>> Это никого не волнует и подрядчик делает это все за свой счет. V>Ну так он может сказать "ну не шмогла я", дайте еще месяц, а затем еще и V>еще. И вы влетаете: переход на другого исполнителя уже будет очень дорог V>и потеря времени и вынуждены идти навстречу этому. V>Понятно, что через еще несколько лет вы откажетесь от этого исполнителя, V>но несколько он вас будет доить. Я такое много раз наблюдал.
Доить, то он не сможет, ему все равно придется это дело фиксить. Если он этого не делается, то нанимается другой подрядчик, а этому выставляется счет. Если он его не оплачивает, то суд. В общем рычагов хватает.
Но в таких случаях обычно идется на встречу исполнителю, он делает сначала какой-нибудь странный костыль, который хоть как-то баг фиксит, а потом уже через какое-то время приходит нормально пофикшенная версия,
вполне возможно, что просто с улучшенным костылем
1/15/2014 5:23 PM, SkyKnight пишет:
> Ну как сказать, в предыдущей конторе был бардак еще тот.
Ты бы хоть похвастался конторой с приличной организацией работы.
1/15/2014 5:30 PM, SkyKnight пишет:
> Но в таких случаях обычно идется на встречу исполнителю, он делает > сначала какой-нибудь странный костыль, который хоть как-то баг фиксит, а > потом уже через какое-то время приходит нормально пофикшенная версия, > вполне возможно, что просто с улучшенным костылем
Ага, то время у вас не сильно важно, можно завтра, а можно и через
несколько месяцев?
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 5:23 PM, SkyKnight пишет:
>> Ну как сказать, в предыдущей конторе был бардак еще тот. V>Ты бы хоть похвастался конторой с приличной организацией работы.
Ну тут тоже есть свои недостаки и свои косяки, зачастую зависит от проекта. Вот есть у нас небольшой филиал в Москве, вот у них бардак полный. У нас в Ашаффенбурге, в прицнипе, организовано хорошо. А в Гамбурге и Дортмунде, тоже не так сладко. У дортмундовского филлиала есть проект со швейцарской почтой, так он уже в минусе около 4 млн евро. У нас тут тоже был проект с немецкой почтой (я еще тут не работал, но должен был быть на нем), тоже лопнул полностью именно из-за срывов сроков.
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 5:30 PM, SkyKnight пишет:
>> Но в таких случаях обычно идется на встречу исполнителю, он делает >> сначала какой-нибудь странный костыль, который хоть как-то баг фиксит, а >> потом уже через какое-то время приходит нормально пофикшенная версия, >> вполне возможно, что просто с улучшенным костылем V>Ага, то время у вас не сильно важно, можно завтра, а можно и через V>несколько месяцев?
Зависит от критичности бага. Если "не тот цвет кнопки", то может и месяц подождать, никто не помрет. А если все валится и из-за него ничего не работает, то тут уже время на часы идет.
1/15/2014 5:38 PM, SkyKnight пишет:
> Зависит от критичности бага. Если "не тот цвет кнопки", то может и месяц > подождать, никто не помрет. А если все валится и из-за него ничего не > работает, то тут уже время на часы идет.
А в ответ "ну не шмогла я". И ганджутас (или как его там с
непроизносимым ником) пытается предупредить эту ситуацию с помощью ревью
кода, по сути просто берет на себя часть работы исполнителя.
Ладно, в общем почитав твой соседний пост, я понял, что это просто
сейчас тебе повезло и пока текущий исполнитель хорошо работает
(вероятнее всего у них есть некая приличная команда, которую скоро
разгонят). А так типичный бардак, как и везде.
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 9:07 AM, kostik78 пишет:
V>Как бы типичная картинка: "я начальник, ты дурак" не лучший вариант V>жизнедеятельности конторы.
Это термин используется только русскими. От амереканцев я обычно слышу что начальнику виднее что надо делать так как он больше знает о бизнес причинах.
V>Ладно, я тебе нарисую веселее ситуацию: есть очень хороший программист, V>но он не хочет делать некий проект, в том числе и по причине того, что V>не не специалист в этой узкой части и проект ему не нравиться. Что V>делать с этим программистом, поручить ему другой проект (такой есть и не V>один) или уволить программиста.
С точки зрения менеджера, програмиста и полезности для компании — поручит другой проект. Тем более заставлять делать проект програмиста не стоит если он говорит что он не специалист в этой области.
И я был в таких ситуациях по обе стороны забора: как програмист, как непосретсвенный менеджер и как вышестоящий менеджер.
On 15.01.2014 19:45, kostik78 wrote:
> V>Как бы типичная картинка: "я начальник, ты дурак" не лучший вариант > V>жизнедеятельности конторы. > Это термин используется только русскими. От амереканцев я обычно слышу > что начальнику виднее что надо делать так как он больше знает о бизнес > причинах.
1/15/2014 6:45 PM, kostik78 пишет:
> Это термин используется только русскими. От амереканцев я обычно слышу > что начальнику виднее что надо делать так как он больше знает о бизнес > причинах.
Просто русские менее толерастны пока.
> С точки зрения менеджера, програмиста и полезности для компании — > поручит другой проект. Тем более заставлять делать проект програмиста не > стоит если он говорит что он не специалист в этой области.
А вот фиг тебе — уволить по тому как посмел не согласиться с
начальником. А да и контору могу назвать (чтобы не назвали, что это
фантазии), все одно она уже сотни раз переименовывалась, тогда они были
АУКТИСОФТ.
1/15/2014 6:53 PM, hrensgory пишет:
> Вот она, политкорректность в действии !
Когда-то я моему французскому начальнику так и написал, что "жираф
большой, ему видней" (правда еще пришлось ссылку на Высоцкого кинуть).
Правда то был француз белого цвета и все его предки были тоже французы
белого цвета и с чувством юмора.
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 6:45 PM, kostik78 пишет:
>> С точки зрения менеджера, програмиста и полезности для компании — >> поручит другой проект. Тем более заставлять делать проект програмиста не >> стоит если он говорит что он не специалист в этой области. V>А вот фиг тебе — уволить по тому как посмел не согласиться с V>начальником. А да и контору могу назвать (чтобы не назвали, что это V>фантазии), все одно она уже сотни раз переименовывалась, тогда они были V>АУКТИСОФТ.
Вы меня спросили как я бы поступил. Я ответил
Здравствуйте, hrensgory, Вы писали:
H>On 15.01.2014 19:45, kostik78 wrote:
>> V>Как бы типичная картинка: "я начальник, ты дурак" не лучший вариант >> V>жизнедеятельности конторы. >> Это термин используется только русскими. От амереканцев я обычно слышу >> что начальнику виднее что надо делать так как он больше знает о бизнес >> причинах.
H>Вот она, политкорректность в действии !
Дело не только в политккоректности. О чень часто непосредственный исполнитель не знает всего скопа задачи и данный проект может быть частью чего то большого. Соответсвено решения могут приниматся странные на его взгляд. Но задача менеджера в данной ситуации обьяснить что надо делать так и по каким причинам на сколько позволяют рамки полномочий. Иногда надо принять просто на слово. В конце концов если ты не доверяешь коллеге, своему менеджеру то что за причина оставатся в этой команде. Мой опыт что удачные тимы это где люди доверяют друг другу и верят на слово как бы банально это не звучало.
H>-- H>WBR, H>Serge.
K>Да это уже не важно в данной ситуации. Руководство компании дало директиву програмисту работать с конторой. Он отказывается и не хочет идти на уступки. В конце концов даже если он 100% прав в данной ситуации то он все равно не имеет никакого права
Поймите: мы выделенного не знаем.
Вы заявили 6 лет опыта руководства 30 сотрудниками в "западной компании". Теперь пишете, что сотрудник не имеет права голоса и должен делать то, что ему велят, либо увольняться. Хотелось бы знать имя и географическое положение этой "западной компании", чтобы, как минимум, стараться в нее не попадать.
Вы не желаете выслушать аргументы сотрудника. Может, он уже пошёл на какой-то компромисс, о котором мы не знаем?
G>Если бы приемкой занимался ты, то быстро бы понял (я надеюсь) что код читать получается быстрее, чем тесты гонять. Особенно в сложных проектах, где недостаточно соотвествия функциональной спецификации.
Не могу с этим согласиться. Особенно если "приёмка" — это не разовый "положили в стол", а периодическое обновление библиотеки или проекта.
Здравствуйте, SkyDance, Вы писали:
K>>Да это уже не важно в данной ситуации. Руководство компании дало директиву програмисту работать с конторой. Он отказывается и не хочет идти на уступки. В конце концов даже если он 100% прав в данной ситуации то он все равно не имеет никакого права
SD>Поймите: мы выделенного не знаем.
Хорошо, читаем на лайфжорнал
=========
Но через неделю я обнаружил, что программист тихо саботирует эти соглашения. Программист выискивает всякие технические зацепки и не дает данные, не пишет ответы, не составляет замечания для подрядчика.
...
И я попробовал убедить программиста, предложив такой вариант:
1. Он остаётся техническим руководителем проекта, делает всё, что хочет.
2. Но он обязать принимать работы и дать возможность подрядчику работать в соответствии с ТЗ.
Позиция программиста:
Я же сам готов всё сделать. Это будет бесплатно и гораздо лучше, чем сделает подрядчик.
Нужно немедленно разорвать контракт с подрядчиком.
Фактически программист ставит невысказанный ультиматут:
— Или я или подрядчик.
=====
SD>Вы заявили 6 лет опыта руководства 30 сотрудниками в "западной компании". Теперь пишете, что сотрудник не имеет права голоса и должен делать то, что ему велят, либо увольняться. Хотелось бы знать имя и географическое положение этой "западной компании", чтобы, как минимум, стараться в нее не попадать.
Пожалуйста — Силиконовая долина но я не работаю в той уже компании. Для себя решил что менеджмент это не та область где я бы хотел расти. Но за 6 лет управления группами у меня уволился только один человек по причине переезда в другой город и я сам уволил двоих — один ничего не делал, другой позволял себе приходить пьяным на работу. А группы наоборот стали еще больше. И более того после того как я покинул компанию некоторые сотрудники пошли за мной. И практически все просили мои рекомендации при устройстве в другие компании.
Также я не где не писал что сотрудник не имеет права голоса. Более того аргументированная дискуссия всегда хорошо для тима. Я же написал, что финальный голос за тем кто платит сотруднику зарплату или его представителем — менеджером. И у сотрудника есть выбор что делать с этим финальным решением — соглашаться или уволнятся. Но ни как не саботировать. Не кажется что это звучит несколько иначе чем Вы пытаетесь представить.
SD>Вы не желаете выслушать аргументы сотрудника. Может, он уже пошёл на какой-то компромисс, о котором мы не знаем?
Я не говорил что я не желаю слушать аргументы сотрудника, не надо это мне приписывать. Мои ответы базируется на той информации что предоставлена в лайжорнал. Вы похоже не желаете почитать что написано. Я специально для Вас вставил кусок от туда который говорит мне что решение уволить сотрудника в данной ситуации является правильным.
Так там программист утверждает что нужно порвать контракт и баста, никаких компромисов. При этом скорее всего он не знает условий разрыва договора или возможных последтвий.
Вы издеваетесь? В журнале односторонне поданное мнение. Некая интерпретация неизвестных нам фактов. Что там на самом деле, мы не знаем. Потому что, повторюсь, мы видим лишь одну сторону медали.
K>Также я не где не писал что сотрудник не имеет права голоса. Более того аргументированная дискуссия всегда хорошо для тима. Я же написал, что финальный голос за тем кто платит сотруднику зарплату или его представителем — менеджером.
Разумеется. Ваш посыл верен.
K>И у сотрудника есть выбор что делать с этим финальным решением — соглашаться или уволнятся. Но ни как не саботировать. Не кажется что это звучит несколько иначе чем Вы пытаетесь представить.
А выводы неверны. Сотрудник может соглашаться, может увольняться, может саботировать. Равно как руководство может соглашаться, увольняться, саботировать или увольнять тех, кого можно уволить. Это не бинарный выбор. Кроме того, с точки зрения сотрудника он может вовсе не саботировать. Может даже выполнять поставленную задачу. А может идти на принцип (см. "итальянская забастовка"). Пока мы не узнаем от непосредственных участников конфликта, что ими движет, какие цели и интересы они преследуют, скоропостижные выводы типа "уволить" я бы делать поостерегся.
Но после того, как вы описали свой карьерный путь, мне стал понятен ваш образ мышления. Какое-то время вы выступали в роли вышестоящего менеджера. Это накладывает свой отпечаток: в качестве ваших доверенных лиц выступают нижестоящий менеджмент. Поэтому в случае конфликта вы поддержите менеджера, особенно, если у вас нет времени на подробный разбор ситуации. Потому что вы знаете своих подчиненных (менеджеров). Программистов, если и знаете, то, как правило, уже не так хорошо и близко. Особенно в "чужих" командах.
K>Так там программист утверждает что нужно порвать контракт и баста, никаких компромисов.
Нет. Там менеджер заявляет, будто программист так утверждает. А что на самом деле — мы не знаем. Равно как мы не знаем, может, в самом деле контракт крайне невыгоден для компании (но может быть выгоден определенным менеджерам компании).
SD>Потому что вы знаете своих подчиненных (менеджеров). Программистов, если и знаете, то, как правило, уже не так хорошо и близко. Особенно в "чужих" командах.
Кстати. Из этого заключения можно сделать несколько важных выводов.
1. Следует помнить, что уровень доверия вышестоящего начальства к вашему непосредственному менеджеру заведомо выше, чем к вам (исключая случаи личных связей).
2. Даже если ваш руководитель профнепригоден, доказать это начальству уровнем выше вам не удастся, если вы будете действовать в одиночку.
3. В случае, если вы — единственный подчиненный, и назревает конфликт или просто недовольство руководителем, попробуйте с минимальными потерями перейти к другому руководителю (в другую команду, отдел, компанию).
Эти, казалось бы, простые вещи понимают и признают далеко не все работники.
Здравствуйте, SkyDance, Вы писали:
SD>Вы издеваетесь? В журнале односторонне поданное мнение. Некая интерпретация неизвестных нам фактов. Что там на самом деле, мы не знаем. Потому что, повторюсь, мы видим лишь одну сторону медали.
Хорошо больше не буду "издеваться" ибо в Ваших словах есть своя "правда".
SD>А выводы неверны. Сотрудник может соглашаться, может увольняться, может саботировать. Равно как руководство может соглашаться, увольняться, саботировать или увольнять тех, кого можно уволить. Это не бинарный выбор. Кроме того, с точки зрения сотрудника он может вовсе не саботировать. Может даже выполнять поставленную задачу. А может идти на принцип (см. "итальянская забастовка"). Пока мы не узнаем от непосредственных участников конфликта, что ими движет, какие цели и интересы они преследуют, скоропостижные выводы типа "уволить" я бы делать поостерегся.
Можно согласится, можно уволится и можно устроить итальянскую забастовку. НО, никогда нельзя саботировать по двум причинам:
1) моральная — сотруднику платят зарплату за выполнение работы и компания заинтересована чтобы сотрудник ее выполнял и не наносил ущерб компании. Соботаж — прямой ущерб и нечестное отношение к компании.
2) юридическая — саботаж это прямое нарушение трудовых отношений между сотрудником и компание. И для сотрудника ведение саботожа черевато юридическими последствиями. По этому я говорю что если не согласен и не хочешь идти на компромис — уволняйся. Это лучше для сотрудника и для компании.
SD>Но после того, как вы описали свой карьерный путь, мне стал понятен ваш образ мышления. Какое-то время вы выступали в роли вышестоящего менеджера. Это накладывает свой отпечаток: в качестве ваших доверенных лиц выступают нижестоящий менеджмент. Поэтому в случае конфликта вы поддержите менеджера, особенно, если у вас нет времени на подробный разбор ситуации. Потому что вы знаете своих подчиненных (менеджеров). Программистов, если и знаете, то, как правило, уже не так хорошо и близко. Особенно в "чужих" командах.
Да Вы правы, что отпечаток имеется. Но имхо очень полезный опыт и знания для меня, когда я сейчас в основном single contributor. Этот отпечаток помогает мне предлагать взвешеные решения которые учитывают обе стороны барикад.
И Вы промахнулись в моем случае, про незнание подчиненых, хотя in general Вы правы. В моем случае я собеседовал каждого человека, и знал в лицо кого я нанимаю. Также я имел привычку проводить one-one с каждым сотрудником раз в 3-4 недели. Это мне позволяло всегда иметь контакт и видеть чем живут мои сотрудники. Также видеть возникающее напряжение и вовремя предотвращать/разрешать его прежде чем это вырастало в проблему.
K>>Так там программист утверждает что нужно порвать контракт и баста, никаких компромисов.
SD>Нет. Там менеджер заявляет, будто программист так утверждает. А что на самом деле — мы не знаем. Равно как мы не знаем, может, в самом деле контракт крайне невыгоден для компании (но может быть выгоден определенным менеджерам компании).
Окей, убедили.
Я старался не переходить на личности, но всетаки один личный вопрос себе позволю если не возражаете. Вы служили в армии (без разницы в какой стране)?
K>Можно согласится, можно уволится и можно устроить итальянскую забастовку. НО, никогда нельзя саботировать
Предположу, что мы по-разному понимаем значение этого термина и его применение к рассматриваемой ситуации. Сомневаюсь, что программист именно саботировал. Честно сказать, я ни разу не видел, чтобы программист именно что-то саботировал (суть разрушал намеренно). Бывало, что просто не выполняли поставленные задачи. И то, как правило, прикрываясь какой-либо текучкой. Но чтоб саботировать — не припомню. Если в вашей практике было, поделитесь.
K>И Вы промахнулись в моем случае, про незнание подчиненых, хотя in general Вы правы. В моем случае я собеседовал каждого человека, и знал в лицо кого я нанимаю. Также я имел привычку проводить one-one с каждым сотрудником раз в 3-4 недели. Это мне позволяло всегда иметь контакт и видеть чем живут мои сотрудники. Также видеть возникающее напряжение и вовремя предотвращать/разрешать его прежде чем это вырастало в проблему.
Довольно распространенная иллюзия. Вряд ли я с вами когда-либо работал, но на основе общих наблюдений предположу, что непосредственным подчиненным вы уделяли на порядок больше времени. И потому были в значительной степени под влиянием их мнения о конкретном сотруднике. Эта норма подробно рассматривается в психологии. Если вы выбрали своего представителя (нижестоящего руководителя), это произошло потому, что вы в нем уверены больше, чем в других. А значит при конфликте мнений поддержите его позицию.
Надеюсь, вы не станете утверждать, что час-другой в неделю (это по моему опыту среднее время с учётом one-on-one и разных вариантов progress meeting) вы в состоянии понять и принять проблемы и точку зрения сотрудника.
K>Вы служили в армии (без разницы в какой стране)?
Да. Но вас, видимо, интересует чуть иной вопрос — служил ли я рядовым? Отвечаю — рядовым — нет.
Здравствуйте, SkyDance, Вы писали:
SD>Надеюсь, вы не станете утверждать, что час-другой в неделю (это по моему опыту среднее время с учётом one-on-one и разных вариантов progress meeting) вы в состоянии понять и принять проблемы и точку зрения сотрудника.
Думаю что эта дискуссия исчерпала себя полностью.
K>>Вы служили в армии (без разницы в какой стране)?
SD>Да. Но вас, видимо, интересует чуть иной вопрос — служил ли я рядовым? Отвечаю — рядовым — нет.
Рядовой, не рядовой — разницы нет. Ну если служили, тогда должны знать что "командир всегда прав. Если не прав то смотри пункт первый" — это не шутка и не издевка. А это суровая правда жизни такая же как воинский устав, который во многих моментах писался кровью.
Так в бизнесе также, тот кто отвечает за компанию или за много людей имеет больше авторити также как и отвествености. (Я упускаю случаи личной заинтересованости менеджеров ака откатов распространеных на територии бывшего СССР и некоторых других стран)
Ну в общем я думаю что мы как то далекова-то отошли от начальной темы. И если честно, то я не очень то хочу обсуждать мою персону дальше и чем движется мое мнение в данной конкретной ситуации. (В особенности на форуме с незнакомыми мне людьми).
P.S. Кстати есть очень древняя поговорка — "Где два человека, там три мнения". Я к тому что очень хорошо, когда в дискусси есть больше одного мнения.
Здравствуйте, SkyDance, Вы писали:
SD>Но чтоб саботировать — не припомню. Если в вашей практике было, поделитесь.
Вспомнил один случай но не в моей команде — когда инженер разработал новую нужную фичу сломав полностью backward compatibility. Так что если бы кастомеры обновились на эту новую версию, у них переставала работать 30% функционала. Так вот позиция инжинера была, что он сделал крутую штуку и то что было до этого фигня. И что остальные не понимают что кастомерам эта фича очень нужна. Дело докатилось почти что-то до президента компании. Инженеру было сказано, что да фича классная но мы должны предоставить обратную совместимость и миграцию для кастомеров. Инженер сказал что ничего делать он не будет потому что так все хорошо. Итог: фича полностью выкошена из продукта моим тимом, инжинер и project manager были уволены. Компания вынуждена была отложить новую версию на 4 месяца. Вот по мне это и есть саботаж.
Здравствуйте, Vzhyk, Вы писали:
V>разгонят). А так типичный бардак, как и везде.
Честно говоря за всю свою профессиональную жизнь я ни разу не встречал конторы где бы все было в полном порядке.
Зачастую было так, что на одном проекте все ништяк, а соседний проект полный трололо.
Но контора, где я сейчас, хотя бы пытается что-то наладить. Прогресс виден (хоть пока и небольшой) в сторону улучшения.
В предыдущей фирме вообще никаких подвижек не было за 3 года, хоть там было наобещано вагон и маленькая тележка. Там даже не было понятно кто за что отвечает.
Здравствуйте, kostik78, Вы писали:
K>Итог: фича полностью выкошена из продукта моим тимом, инжинер и project manager были уволены. Компания вынуждена была отложить новую версию на 4 месяца. Вот по мне это и есть саботаж.
Эффективные менеджеры, такие эффективные. А перед тем как давать инженеру задание, в список требований внести обратную совместимость нельзя было? Код ревью у эффективных менеджеров тоже не в почете? Зато увольнения и срыв сроков, да, это пожалуйста. Вот по мне это и есть саботаж.
1/16/2014 3:49 AM, SkyDance пишет:
> 1. Следует помнить, что уровень доверия вышестоящего начальства к вашему > непосредственному менеджеру заведомо выше, чем к вам (исключая случаи > личных связей). > 2. Даже если ваш руководитель профнепригоден, доказать это начальству > уровнем выше вам не удастся, если вы будете действовать в одиночку. > 3. В случае, если вы — единственный подчиненный, и назревает конфликт > или просто недовольство руководителем, попробуйте с минимальными > потерями перейти к другому руководителю (в другую команду, отдел, компанию). > > Эти, казалось бы, простые вещи понимают и признают далеко не все работники.
Это очень сложно признавать, особенно, когда делают что очень крутое и
интересное. Поэтому люди и понимают, но не хотят верить в реальность.
Оно то понятно, все заканчивается полным развалом у подобных руками
водителей, но может тянутся сей процесс многие года.
1/16/2014 7:35 AM, kostik78 пишет:
> Итог: фича полностью выкошена из продукта моим тимом, инжинер и project > manager были уволены. Компания вынуждена была отложить новую версию на 4 > месяца. Вот по мне это и есть саботаж.
Это полная безграмотность менеджмента на той конторе.
1/16/2014 10:12 AM, SkyKnight пишет:
> Честно говоря за всю свою профессиональную жизнь я ни разу не встречал > конторы где бы все было в полном порядке. > Зачастую было так, что на одном проекте все ништяк, а соседний проект > полный трололо.
Вот поэтому ты и вызвал у меня бурю удивления.
> Но контора, где я сейчас, хотя бы пытается что-то наладить. Прогресс > виден (хоть пока и небольшой) в сторону улучшения.
Молодцы. Нынче и это из ряда вон выходящая картинка. Все делают вид, что
что-то делают и после совместных распитий все прекрасно принимается, а у
принимающих машины обновляются.
1/16/2014 10:28 AM, MTD пишет:
> Эффективные менеджеры, такие эффективные. А перед тем как давать > инженеру задание, в список требований внести обратную совместимость > нельзя было? Код ревью у эффективных менеджеров тоже не в почете? Зато > увольнения и срыв сроков, да, это пожалуйста. Вот по мне это и есть саботаж.
Да бог с ним с требованиями и ревью, нафига ту правку в продакшен пускать?
Ну сделал крутую и хорошую вещь, молодец, она же в отдельной ветке и
откладывается, пока не будет нормально слита с продакшен, без поломки
работающей функциональности. Головная боль по сливанию понятно на этом
инженере.
З.Ы. Телепалку включать лень и так все понятно, какой бардак на
означеной конторе.
Здравствуйте, gandjustas, Вы писали:
G>А еще можно ревью автоматизировать тулами, тогда анализ кода делается примерно в 10 раз быстрее, если код написан нормально.
Читал это высказывание. Смотрел в картинку в твоей подписи. Вспоминал анекдот про "либо крестик, либо трусы". Много думал.
Здравствуйте, SkyDance, Вы писали:
SD>Ага, потому что программист уволится. Конечно, если он не дурак. Опытные программисты прекрасно понимают — как только у них требуют работать за себя, а также за аналитиков, program manager'ов, юзабилистов и других персон, это лишь означает, что их довольно бездарно "разводят".
Но он же сам на это напрашивается?
Чем совершеннее технически средство, тем более примитивные, никчемные и бесполезные сведения при его помощи передаются.(с)Станислав Лем
Здравствуйте, Vzhyk, Вы писали:
V>1/16/2014 7:35 AM, kostik78 пишет:
>> Итог: фича полностью выкошена из продукта моим тимом, инжинер и project >> manager были уволены. Компания вынуждена была отложить новую версию на 4 >> месяца. Вот по мне это и есть саботаж. V>Это полная безграмотность менеджмента на той конторе.
Не менеджера а проджек менеджера который спустил все на тормоза и во время не эскалировал.
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, kostik78, Вы писали:
K>>Итог: фича полностью выкошена из продукта моим тимом, инжинер и project manager были уволены. Компания вынуждена была отложить новую версию на 4 месяца. Вот по мне это и есть саботаж.
MTD>Эффективные менеджеры, такие эффективные. А перед тем как давать инженеру задание, в список требований внести обратную совместимость нельзя было? Код ревью у эффективных менеджеров тоже не в почете? Зато увольнения и срыв сроков, да, это пожалуйста. Вот по мне это и есть саботаж.
Опять же Ваше предположение. В списке требований к фиче обратная совместимость была. Инженер просто забил на нее ибо это сильно мешало ему. Опять же со слов инженера. Код ревью в данном случае был пропушен в виду неизвестных мне причин и инженер работал один.
Здравствуйте, Vzhyk, Вы писали:
V>1/16/2014 10:28 AM, MTD пишет:
>> Эффективные менеджеры, такие эффективные. А перед тем как давать >> инженеру задание, в список требований внести обратную совместимость >> нельзя было? Код ревью у эффективных менеджеров тоже не в почете? Зато >> увольнения и срыв сроков, да, это пожалуйста. Вот по мне это и есть саботаж. V>Да бог с ним с требованиями и ревью, нафига ту правку в продакшен пускать? V>Ну сделал крутую и хорошую вещь, молодец, она же в отдельной ветке и V>откладывается, пока не будет нормально слита с продакшен, без поломки V>работающей функциональности. Головная боль по сливанию понятно на этом V>инженере.
в 1999 и 2000 году я не особо слышал чтобы активно использовались бранчи для девелопмента особенно при использовании Perforce. Стоимость усилий обратного мержа зашкаливала. Но в целом Вы правы.
1/16/2014 5:40 PM, kostik78 пишет:
> Не менеджера а проджек менеджера
А менеджер, который не про джек, это уже и не менеджер совсем, а так
джек, который PRO из без кислородной меди.
1/16/2014 5:45 PM, kostik78 пишет:
> в 1999 и 2000 году я не особо слышал чтобы активно использовались бранчи > для девелопмента особенно при использовании Perforce. Стоимость усилий > обратного мержа зашкаливала. Но в целом Вы правы.
Да какая разница perforce там, cvs или просто исходники архивируют по
версиям. Суть в полном отсутствии какой-либо организации работы.
Здравствуйте, Vzhyk, Вы писали:
V>1/16/2014 5:45 PM, kostik78 пишет:
>> в 1999 и 2000 году я не особо слышал чтобы активно использовались бранчи >> для девелопмента особенно при использовании Perforce. Стоимость усилий >> обратного мержа зашкаливала. Но в целом Вы правы. V>Да какая разница perforce там, cvs или просто исходники архивируют по V>версиям. Суть в полном отсутствии какой-либо организации работы.
Ага, расказывайте мне. "Если мы все такие умные то почему такие бедные" (с)
Организация работы в данной компании была не чета многим существующим новомодным методикам. И релиз был задержан только один раз в описанном мной случае. Продукт насчитывал несколько милионов строчек кода на С/С++.
Кстати, мои наблюдения. Позиция многих инженеров — все "дураки" я один такой "дартаньян" и знаю как все надо делать правильно. А менеджеры просто лодыри. Но как только ему предлагают взят и вести проект from ground который требует межкомандного общения — типичный ответ, что ему за это не платят. Что собственно понятно, очень легко критиковать но гораздо труднее сделать. Это так рилическое отступление.
1/16/2014 6:14 PM, kostik78 пишет:
> Ага, расказывайте мне. "Если мы все такие умные то почему такие бедные" (с)
С этим в Эклезиаст.
> Организация работы в данной компании была не чета многим существующим > новомодным методикам. И релиз был задержан только один раз в описанном > мной случае.
Не верю. (с)
Здравствуйте, Vzhyk, Вы писали:
V>1/16/2014 6:14 PM, kostik78 пишет:
>> Ага, расказывайте мне. "Если мы все такие умные то почему такие бедные" (с) V>С этим в Эклезиаст.
>> Организация работы в данной компании была не чета многим существующим >> новомодным методикам. И релиз был задержан только один раз в описанном >> мной случае. V>Не верю. (с)
Ваше право.
Здравствуйте, kostik78, Вы писали:
K>Кстати, мои наблюдения. Позиция многих инженеров — все "дураки" я один такой "дартаньян" и знаю как все надо делать правильно. А менеджеры просто лодыри.
Кстати, их жизненная позиция имеет под собой часто основания. Потому как большой начальник — это плюс прибыль минус ответственность. Достаточно в телевизор посмотреть, чтобы осознать что чем выше начальник, тем большая он сволочь. И от его (инженера) прямого начальника, независимо от степени затраханности последнего, дорожка к мерзавцам АКА "Уважаемым Людям" гораздо короче, чем с его пролетария умственного труда ступени.
Здравствуйте, avgur, Вы писали:
A>Здравствуйте, kostik78, Вы писали:
K>>Кстати, мои наблюдения. Позиция многих инженеров — все "дураки" я один такой "дартаньян" и знаю как все надо делать правильно. А менеджеры просто лодыри.
A>Кстати, их жизненная позиция имеет под собой часто основания. Потому как большой начальник — это плюс прибыль минус ответственность. Достаточно в телевизор посмотреть, чтобы осознать что чем выше начальник, тем большая он сволочь. И от его (инженера) прямого начальника, независимо от степени затраханности последнего, дорожка к мерзавцам АКА "Уважаемым Людям" гораздо короче, чем с его пролетария умственного труда ступени.
Это не так в небольших частных компаниях и стартапах. Там как правильно начальник несет больше ответсвенности и делает гораздо больше работы (но другой работы) чем простые работники. Так что имхо это удобный excuse для инженеров.
Пока что я видел немного примеров когда инженер все-таки соглашался взять новый проект и довести его до конца не только как single contributor но и как настоящий tech lead. За то видел много примеров когда инженеры критиковали и говорили что они сделали бы лучше, но отказывались показать себя на практике.
1/16/2014 9:01 PM, kostik78 пишет:
> Пока что я видел *немного* примеров когда инженер все-таки соглашался > взять новый проект и довести его до конца не только как single > contributor но и как настоящий tech lead.
От таких после окончания проекта стараются избавиться ибо или проект
такого же уровня надо дать или сложнее, а они не часто появляются, или
надоедать будет.
З.Ы. Да, все что я пишу, это все из своего опыта, то что видел или сам
участвовал.
Здравствуйте, Vzhyk, Вы писали:
V>1/16/2014 9:01 PM, kostik78 пишет:
>> Пока что я видел *немного* примеров когда инженер все-таки соглашался >> взять новый проект и довести его до конца не только как single >> contributor но и как настоящий tech lead. V>От таких после окончания проекта стараются избавиться ибо или проект V>такого же уровня надо дать или сложнее, а они не часто появляются, или V>надоедать будет.
Таких ценить надо а не избавляться. А проекты можно всегда найти. Правда я не говорю про аутсорсеров. На них не работал никогда, но слышал что там своя специфика.
V>З.Ы. Да, все что я пишу, это все из своего опыта, то что видел или сам V>участвовал.
Я тоже как не странно
Здравствуйте, kostik78, Вы писали:
K>Пока что я видел немного примеров когда инженер все-таки соглашался взять новый проект и довести его до конца не только как single contributor но и как настоящий tech lead. За то видел много примеров когда инженеры критиковали и говорили что они сделали бы лучше, но отказывались показать себя на практике.
А я видел много примеров, когда инженер предлагал что-то дельное и готов был брать на себя ответственность, но его от греха подальше увольняли или игнорировали, пока он сам не уходил. Почему? Да потому, что тут менеджеру надо подумать и согласится на риск, а и то и другое ему не очень хочется.
Здравствуйте, kostik78, Вы писали:
K>Таких ценить надо а не избавляться. А проекты можно всегда найти.
В мелкой и адекватной конторе да, ценить. В большой на такого выскочку скорее всего будут как минимум недовольно коситься и выдавят при удобном случае.
1/16/2014 9:12 PM, MTD пишет:
>Да потому, что тут > менеджеру надо подумать и согласится на риск, а и то и другое ему не > очень хочется.
Все еще проще, очень часто это выглядит в глазах этого менеджера, что он
не справился и боится, что инженер его подсиживает. Как результат
основная задача этого менеджера избавиться от этого инженера, а проект
это уже третье — практически всегда можно сказать, что "ну не шмогла я"
ну и обвинить уволенного инженера, что это тот виноват.
Извините, но вот это: _AB>Если комменты почитать, то да, там примерно так и было. Конфликт этот уладили. _AB>Предыдущий конфликт (в котором была вина подрядчика) улажен.
как-то не сочетается с этим: _AB>Основная проблема с этим программером, что он рогом уперся и не хочет работать с подрядчиком, а хочет сам писать всё с нуля.
Может быть, у вас какое-то другое представление о том, как надо улаживать конфликты, но по-моему конфликт считается улаженым тогда и только тогда, когда все стороны согласны с предложенным решением и сняли все свои претензии и возражения. В данной ситуации мнение программиста скорее всего было проигнорировано. А упирается он, возможно, потому, что понимает, что ему предстоит данный велосипед поддерживать в дальнейшем. Да, начальство наверняка пожурят на митинге, возможно, даже выпишут наказание в виде строгого взгляда директора, но вот сидеть ночами и допиливать код будут не они, а программист.
сабот’аж, -а, м. Преднамеренное расстройство или срыв работы при соблюдении видимости её выполнения, а также вообще скрытое противодействие исполнению, осуществлению чего-н.
Если настоящей целью инженера было доставить вред — тогда это мог бы быть саботаж. Но, если я верно понял ситуацию, он не стремился к этому сознательно.
Если все было именно так, как вы описываете — ситуация классическая, которую в определенных кругах называют "нанести непоправимую пользу".
K>Итог: фича полностью выкошена из продукта моим тимом, инжинер и project manager были уволены. Компания вынуждена была отложить новую версию на 4 месяца.
Как вы, наверное, уже догадались, я не могу обсуждать ваш конкретный случай без знания деталей: что, как, почему, кто был прав и к чему привело дальнейшее развитие упомянутого вами программного продукта. Подобные истории есть и у меня. Среди них две особенно показательных. Одна — в моей команде.
Все начиналось близко к описанному вами. С некоторой разницей в том, что разработчик видел тренд развития конкурирующих продуктов и точно предсказывал, что и когда появится, и что будет востребовано в будущем. Разработчик предлагал существенные архитектурные изменения. Но, видимо, будучи в меру опытным, разработчик не встал в позу "костьми лягу, но не позволю выкосить". Просто попросил выйти из проекта, задокументировать его предложения на будущее, завести соответствующие тикеты и т.п.. Вздохнув с облегчением, руководитель закрыл всё это к чертям, выкосил "непоправимую пользу". На перешедшего разработчика свалили шишки за задержку релиза (выглядит похоже на вашу ситуацию, да?), а через два года проект по сути загнулся. Остался только maintenance для старых клиентов, которых сейчас всё меньше и меньше по причине отсутствия развития проекта — ставшего невозможным без проведения очень масштабного рефакторинга. Который, по сути, был бы переходом на новую архитектуру. Ту самую, что была предложена ушедшим разработчиком, или близкую к тому. Занятный факт, что конкурирующий продукт нынче имеет очень близкую архитектуру. Сомневаюсь, что это дело рук того разработчика, просто разумный подход к проектированию рождает похожие решения.
Руководитель тогда вовремя срулил после "успешного релиза". Поставившего, по сути, крест на проекте. Что здесь стало саботажем? И с каких позиций рассматривать этот вопрос, с краткосрочных, или с долгосрочных?
Вторая история была не у меня, но я ее наблюдал с близкого расстояния. Аналогичная ситуация, хотя кроме разработчика там еще руку приложил program manager, который знал, что действительно было нужно для развития проекта. Там не удавалось полностью обеспечить обратную совместимость, и, как в вашем случае, произошел takeover проекта другой командой, включая замену project и program manager (большинство разработчиков осталось). Снаружи всё выглядело как у вас. Но настоящая причина была, гм, "внутренней". Тем самым, что называют "подковёрными играми". Или rat races, или "корпоративными междусобойчиками". Реальной целью был захват. Внедрение ломающей совместимость фичи — повод для обвинения в некомпетентности. Вышестоящий менеджер не имел времени, возможности или желания разобраться и санкционировал захват.
А фича? Потом появилась, с частичной совместимостью. С помпой и как большое достижение нового менеджера.
K>Пока что я видел немного примеров когда инженер все-таки соглашался взять новый проект и довести его до конца не только как single contributor но и как настоящий tech lead.
Это принципиально разные умения: работа крупными мазками (архитектура, прототип, начальные стадии) и окончательная шлифовка проекта. Разработчики, как правило, тяготеют к первому варианту — сделать крупные и интересные части. Лид (и менеджер) не имеют права опускать мелкие детали, ибо дьявол, как известно, в них.
K>За то видел много примеров когда инженеры критиковали и говорили что они сделали бы лучше, но отказывались показать себя на практике.
Я видел и обратные примеры. Следует понимать, что инженеру действительно не платят за "сделал лучше". По крайней мере на первых порах. А нагрузка вырастает очень заметно: приходится учиться и разбираться в не всегда интересных мелочах и деталях. Если этот барьер (порог вхождения) преодолеть, дальше все идет относительно гладко. По крайней мере до тех пор, пока инженер не начинает осознавать, что ему это попросту неинтересно, и не возвращается к тому, что ему больше по душе.
MTD>А я видел много примеров, когда инженер предлагал что-то дельное и готов был брать на себя ответственность, но его от греха подальше увольняли или игнорировали, пока он сам не уходил. Почему? Да потому, что тут менеджеру надо подумать и согласится на риск, а и то и другое ему не очень хочется.
Представь себя на месте менеджера. У тебя уже 30-40 рисков, и тебе предлагают еще один. И сроки уже на подходе. А еще жена беременна.
Здравствуйте, SkyDance, Вы писали:
K>>За то видел много примеров когда инженеры критиковали и говорили что они сделали бы лучше, но отказывались показать себя на практике.
SD>Я видел и обратные примеры. Следует понимать, что инженеру действительно не платят за "сделал лучше". По крайней мере на первых порах. А нагрузка вырастает очень заметно: приходится учиться и разбираться в не всегда интересных мелочах и деталях. Если этот барьер (порог вхождения) преодолеть, дальше все идет относительно гладко. По крайней мере до тех пор, пока инженер не начинает осознавать, что ему это попросту неинтересно, и не возвращается к тому, что ему больше по душе.
Дык мне как раз это обьяснять не надо. Я все это прошел снизу до верху и обратно в single contributor. Я все это понимаю. Плюс дополнительно работа на директорской позиции дало мне понимание бизнес стороны проектов или их кусочков. Какие сложности на уровне управления ими и людьми, что такое бюджет, какие бизнес обязательства и последствия не выполнения оных и т.д. Сейчас мне эти все знания сильно помогают в инженерской работе, имхо.
Я же пытался сказать что критиковать мы все горазды а вот показать на деле какие мы не многие соглашаються.
Здравствуйте, SkyDance, Вы писали:
MTD>>А я видел много примеров, когда инженер предлагал что-то дельное и готов был брать на себя ответственность, но его от греха подальше увольняли или игнорировали, пока он сам не уходил. Почему? Да потому, что тут менеджеру надо подумать и согласится на риск, а и то и другое ему не очень хочется.
SD>Представь себя на месте менеджера. У тебя уже 30-40 рисков, и тебе предлагают еще один. И сроки уже на подходе. А еще жена беременна.
Мы тут много писали про сложности програмистов которые создаются менеджерами. Давайте посмотрим пример с другой стороны окопа. Хоть я практически уверен что большиство скажет что сам дурак, вот реальный пример.
Переставим компанию которая предоставляет некий облачный сервис. Своего кастомер саппорта нет и 1-2 линия аутсорситься. Каждый звонок стоит XX доларов. Сервис имеет несколько интеграции со стороними сервисами/партнерами. В один прекрасный день один партнер падает и начинает таймаутит реквесты. Как бы не беда, так как основной сервис предоставляется и большого количества звонков не ожидается. Но через некоторое время оперейщен начинает бить тревогу что выросла нагрузка на базы данных. Директор идет к главному разработчику который делал интеграцию с этим партером и пытается выяснить что ожидать дальше: достигнет лоад критической отметки или не достигнет. Разработчик почасав репу и посмотрев в код сказал что не знает точно но лучше бы выключить фичу, так как это ничему не повредить. Ок что сказано то сделано, выключили. Но как оказалось выключение фичи привело к пропаданию одной странички на веб интерфейсе что привело к шквалу звонков в саппорт.
Итог: компания потеряла XXXXX долларов за полдня. Директор получил люлей от президента компании. Инженер конечно тут как бы напрямую не виноват и ни кто его не винил в данных убытка в последствии. Но если бы он сказал про пропадание странички то решение возможно было другим.
K> <...> Директор идет к главному разработчику <...> Разработчик почасав репу и посмотрев в код сказал что не знает точно но лучше бы выключить фичу, так как это ничему не повредить. K>Итог: компания потеряла XXXXX долларов за полдня. Директор получил люлей от президента компании. Инженер конечно тут как бы напрямую не виноват и ни кто его не винил в данных убытка в последствии. Но если бы он сказал про пропадание странички то решение возможно было другим.
Для начала перефразируем. Руководитель спросил у инженера — тот ответил "не знаю точно". Ответственность за дальнейшие решения, очевидно, лежит на руководителе. В частности, ему бы следовало уточнить этот момент. Возможно, у других сотрудников. Еще более правильным подходом было бы запустить автоматизированные тесты и выяснить, что может сломаться, если отключить такую-то фичу. Если система столь серьезна, что пол-дня отломанной малозаметной фичи стоили ХХХХХ долларов, мне даже на минуточку сложно представить себе отсутствие более-менее автоматизированного тестирования.
В целом ситуация занятная: один инженер принимает решения ценой в десятки тысяч долларов. Без дОлжного контроля, на основе "почесал репу". Это заведомо взрывоопасная ситуация. Не в этот раз, так в другой обязательно выстрелит. И не факт, что на такую маленькую сумму. Легко и до закрытия бизнеса может дойти. Выходит, от этого инженера зависит здоровье бизнеса? Стало быть, потенциальный уровень ответственности у него очень высок. Наверное, он получает соответствующую компенсацию за это... ведь получает же? Или как обычно, "зарплата техлида"?
Теперь о последствиях. Прекрасно знаю ощущения директора и его чувства. Сомневаюсь, что большинство посетителей сайта понимает, о чем речь. С точки зрения программиста "тяжелый взгляд президента исподлобья" — это и не наказание вовсе, а так, мягко по приятельски пожурить. Для директора же это может стать гирей в чаше весов, стрелка которых неумолимо движется к "нам придется расстаться". В отличие от программиста, который завтра выйдет к соседям работать, бывшему директору придется несколько проблемнее. НО! Кто в этом виноват? Очевидно, сам директор — ведь это в его обязанности входит поддержка такого процесса разработки, при котором "почесал репу и отключил фичу" не нанесет компании существенного вреда.
Здравствуйте, SkyDance, Вы писали:
SD>Для начала перефразируем. Руководитель спросил у инженера — тот ответил "не знаю точно". Ответственность за дальнейшие решения, очевидно, лежит на руководителе. В частности, ему бы следовало уточнить этот момент. Возможно, у других сотрудников. Еще более правильным подходом было бы запустить автоматизированные тесты и выяснить, что может сломаться, если отключить такую-то фичу. Если система столь серьезна, что пол-дня отломанной малозаметной фичи стоили ХХХХХ долларов, мне даже на минуточку сложно представить себе отсутствие более-менее автоматизированного тестирования.
Всетаки разработчик сказал "что не знаю точно, но вреда принести не должно". Это как бы ответ человека который проектировал и разрабатывал интеграцию и должен знать все "итимности сей интеграции". Вы бы на месте директора что сделали при условиях что алтернатива только ручной регрешен 3 QA инженеров на 6-8 часов?
Пол дня стоили из за того что отключение малозаметной фичи привело к попаданию страницы которая являлась закладкой на главной странице. И страница та сама по себе тоже не важная но на ее отсутсвие кастомеры стали беспокоиться и звонить в кастомер саппорт-сторонюю компанию, которая с радостью зачаржила компанию за каждый звонок.
SD>Теперь о последствиях. Прекрасно знаю ощущения директора и его чувства. Сомневаюсь, что большинство посетителей сайта понимает, о чем речь. С точки зрения программиста "тяжелый взгляд президента исподлобья" — это и не наказание вовсе, а так, мягко по приятельски пожурить. Для директора же это может стать гирей в чаше весов, стрелка которых неумолимо движется к "нам придется расстаться". В отличие от программиста, который завтра выйдет к соседям работать, бывшему директору придется несколько проблемнее. НО! Кто в этом виноват? Очевидно, сам директор — ведь это в его обязанности входит поддержка такого процесса разработки, при котором "почесал репу и отключил фичу" не нанесет компании существенного вреда.
В целом Вы все правильно говорите. Но в нашей жизни гораздо больше серого, чем белого или черного. Иногда прогнать фулл регрешен тесты это от нескольки часов до дня, а в некоторых случаев это только ручной регрешен тестинг. И отвлекать людей каждый раз тоже стоит заметных денег и приводит к рискам срыва других проектов. Так что директор вынужден искать разумную алернативу и идти на определенные риски доверяяя своим разработчикам, которые иногда не оценив все за и против обстоятельно подводят своего начальника.
А к чему я это — хочется чтобы всетаки разработчики задумались и обратили внимание что ихнее руководство всетаки не штаны просиживает как многие здесь пытаются представить. Конечно есть плохие исключения но они есть также и на стороне разработчиков.
Здравствуйте, koandrew, Вы писали:
K>Может быть, у вас какое-то другое представление о том, как надо улаживать конфликты, но по-моему конфликт считается улаженым тогда и только тогда, когда все стороны согласны с предложенным решением и сняли все свои претензии и возражения. В данной ситуации мнение программиста скорее всего было проигнорировано.
Давай я не буду пересказывать комменты из исходного поста? Если интересно — почитай.
Если нет, то домысливать не надо.
Здравствуйте, kostik78, Вы писали:
K> Но как только ему предлагают взят и вести проект from ground который требует межкомандного общения — типичный ответ, что ему за это не платят. Что собственно понятно, очень легко критиковать но гораздо труднее сделать.
Дык эта.... А просто платить инженеру за ведение проекта — не пробовали?
Разумеется, любой работник, если его попытаются нагрузить дополнительными обязанностями без адекватного изменения в зарплате — будет отбрыкиваться руками и ногами.
Здравствуйте, kostik78,
K> В списке требований к фиче обратная совместимость была. Инженер просто забил на нее ибо это сильно мешало ему. Опять же со слов инженера. Код ревью в данном случае был пропушен в виду неизвестных мне причин и инженер работал один.
Оба-на! Вот тебе, бабушка, и Юрьев день.... Инженер "просто забил" на требование. Причем — важное с точки зрения бизнеса. А чем в это время занимался его непосредственный начальник? И как тогда эта версия/сборка смогла пройти тестирование и испытания? А если не прошла — она не могла попасть в продакшен... Или все-же попала?
Разруха — она не в клозетах, да-с.
1/17/2014 1:45 AM, SkyDance пишет:
> Представь себя на месте менеджера.
Что тут ставить, сам был не раз на оном месте. Но я обычно старался
объяснить предлагателю почему в текущий момент мы это реализовать
позволить себе не можем. И даже, если председателю давалось добро на
реализацию, я соломку стелил — организовывал работу так, чтобы на откат
к старому тратилось не более пары дней (очко-то не железное).
1/17/2014 1:47 AM, SkyDance пишет:
> Поверьте, менеджер это прекрасно осознает.
Менеджеры ну очень разные бывают и часто качественный опыт и знания у
них только в одном — умении работать языком (если начну приводить
примеры с названиями контор меня здесь забанят, есть фирмы о которых
можно говорить только, как о мертвых, да и мне лишние срачи поднимать
неохота).
А тот, который осознает, он всегда может обосновано объяснить почему
сейчас это реализовывать нельзя, организовать работу так, чтобы
реализация не сломала уже работающее и объяснить, когда можно будет
делать эту реализацию. А да, предлагающие в 99.9 случаях понимают
объяснения и не ведут ситуацию к описанной в первом посте.
1/17/2014 3:29 AM, kostik78 пишет:
> Плюс дополнительно > работа на директорской позиции дало мне понимание бизнес стороны > проектов или их кусочков. > > Я же пытался сказать что критиковать мы все горазды а вот показать на > деле какие мы не многие соглашаються.
Как-то эти 2 высказывания плохо согласуются.
1/17/2014 3:53 AM, kostik78 пишет:
> Разработчик почасав > репу и посмотрев в код сказал что не знает точно но лучше бы выключить > фичу, так как это ничему не повредить. Ок что сказано то сделано, > выключили.
> ни кто его не винил в данных убытка в последствии. Но если бы он сказал > про пропадание странички то решение возможно было другим.
Великолепный пример. Инженер — бог?
1/17/2014 8:27 AM, kostik78 пишет:
> А к чему я это — хочется чтобы всетаки разработчики задумались и > обратили внимание что ихнее руководство всетаки не штаны просиживает как > многие здесь пытаются представить.
В данном примере просиживает и не более.
Ни в коему случае не поступил бы так, как описано тобой. Только через
тестирование и очень нежные аккуратные пробы, чтобы если что не так
максимально быстро все вернуть в рабочее состояние. Толстый слой соломки
сначала, а потом уже и прыгать.
Здравствуйте, kostik78, Вы писали:
K>Всетаки разработчик сказал "что не знаю точно, но вреда принести не должно". Это как бы ответ человека который проектировал и разрабатывал интеграцию и должен знать все "итимности сей интеграции". Вы бы на месте директора что сделали при условиях что алтернатива только ручной регрешен 3 QA инженеров на 6-8 часов?
В прицнипе тут главное, что инженер не на 100% был уверен в своем ответе. В этом случае уже вышестоящему руководству надо было как-то задуматься, хотя бы на пару минут.
Даже если инженер мне скажет, что "мамой клянусь, все будет ништяк", я все равно протестирую перед тем как выкатывать что-либо. Иначе при любом косяке мешок люлей дадут мне и заказчики и начальство.
Здравствуйте, Vzhyk, Вы писали:
V>1/17/2014 8:27 AM, kostik78 пишет:
>> А к чему я это — хочется чтобы всетаки разработчики задумались и >> обратили внимание что ихнее руководство всетаки не штаны просиживает как >> многие здесь пытаются представить. V>В данном примере просиживает и не более.
V>Ни в коему случае не поступил бы так, как описано тобой. Только через V>тестирование и очень нежные аккуратные пробы, чтобы если что не так V>максимально быстро все вернуть в рабочее состояние. Толстый слой соломки V>сначала, а потом уже и прыгать.
Что и требовалось доказать. Что было бы не сказано или сделано, менеджер всегда "виноват" на rsdn. Честно говоря я другого не ожидал. Очень четко прослеживается данная линия в других ветках где заходит разговор про менеджеров.
Здравствуйте, Vzhyk, Вы писали:
V>1/17/2014 3:29 AM, kostik78 пишет:
>> Плюс дополнительно >> работа на директорской позиции дало мне понимание бизнес стороны >> проектов или их кусочков. >> >> Я же пытался сказать что критиковать мы все горазды а вот показать на >> деле какие мы не многие соглашаються. V>Как-то эти 2 высказывания плохо согласуются.
Ну как я уже говорил — Ваше право.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, kostik78, Вы писали:
K>> Но как только ему предлагают взят и вести проект from ground который требует межкомандного общения — типичный ответ, что ему за это не платят. Что собственно понятно, очень легко критиковать но гораздо труднее сделать.
V_S>Дык эта.... А просто платить инженеру за ведение проекта — не пробовали? V_S>Разумеется, любой работник, если его попытаются нагрузить дополнительными обязанностями без адекватного изменения в зарплате — будет отбрыкиваться руками и ногами.
Предлагал — нормальную премию по успешному завершению проекта. С последующим увеличением зарплаты при годовом performance review. Пару человек бралось но по середине проекта стали забивать на организиционные "мелочи" Приходилось вмешиватся что бы проект не загнулся.
Здравствуйте, kostik78, Вы писали:
K>Что и требовалось доказать. Что было бы не сказано или сделано, менеджер всегда "виноват" на rsdn. Честно говоря я другого не ожидал. Очень четко прослеживается данная линия в других ветках где заходит разговор про менеджеров.
Да. Я всегда так считал и считаю и когда менеджерил и когда не менеджерил. Он принимает решения и отвечает за них. А линейные разработчики должны просто делать качественно те задачи, что им поставили — и их ответсвенность только в этом.
1/17/2014 4:36 PM, kostik78 пишет:
> Предлагал — нормальную премию по успешному завершению проекта. С > последующим увеличением зарплаты при годовом performance review. Пару > человек бралось но по середине проекта стали забивать на организиционные > "мелочи" Приходилось вмешиватся что бы проект не загнулся.
Потому что предлагать надо не всем, а только тем, кто способен
организоваться (организовать) и довести дело до конца. На это ты и
руководитель, чтобы знать, кто и что может, а кто и что не может.
Это все выясняется в процессе работы постановкой задач разного уровня и
отслеживание того, как человек их выполняет.
Есть море высококлассных программистов, которые не просто не могут даже
месяц самостоятельно работать, а их работу надо отслеживать каждые
несколько дней. Я уже не говорю о самостоятельном выполнении проекта.
З.Ы. Ты извини, но тобой написанное больше характеризует тебя как
"эффективного менеджера", как совет проанализируй свои действия как
руководителя. Какие книжки почитай, по психологии той же, психологии
коллектива.
Здравствуйте, Vzhyk, Вы писали:
V>Здравствуйте, kostik78, Вы писали:
K>>Что и требовалось доказать. Что было бы не сказано или сделано, менеджер всегда "виноват" на rsdn. Честно говоря я другого не ожидал. Очень четко прослеживается данная линия в других ветках где заходит разговор про менеджеров. V>Да. Я всегда так считал и считаю и когда менеджерил и когда не менеджерил. Он принимает решения и отвечает за них. А линейные разработчики должны просто делать качественно те задачи, что им поставили — и их ответсвенность только в этом.
Дык в данном пример отвественность как раз осталась на директоре, и он ее не делигировал на разработчика
З.Ы. Чтобы отсеять возможный вопрос, в данном примере я участвовал как главный разработчик а не директор. И мой персональный фаулт в данной ситуции был — я не учел возможные последствия для UI и не сказал об этом своем начальнику. И считаю что это моя вина а не директора, который доверяет мне.
Здравствуйте, kostik78, Вы писали:
K>З.Ы. Чтобы отсеять возможный вопрос, в данном примере я участвовал как главный разработчик а не директор. И мой персональный фаулт в данной ситуции был — я не учел возможные последствия для UI и не сказал об этом своем начальнику. И считаю что это моя вина а не директора, который доверяет мне.
Есть потрясающий принцип: Доверяй, но проверяй. Без него, к сожалению, в IT ну совсем никак. Именно в таких случаях лучше собрать несколько мнений, не плохо так же спросить тестовый отдел, потому что они могут знать последствия выкидывания той или иной фичи лучше, нежели разработчик, который даже эту фичу и писал, но не знает по каким-то причинам где она еще может использоваться.
Здравствуйте, Vzhyk, Вы писали:
V>1/17/2014 4:36 PM, kostik78 пишет:
V>Потому что предлагать надо не всем, а только тем, кто способен V>организоваться (организовать) и довести дело до конца. На это ты и V>руководитель, чтобы знать, кто и что может, а кто и что не может. V>Это все выясняется в процессе работы постановкой задач разного уровня и V>отслеживание того, как человек их выполняет. V>Есть море высококлассных программистов, которые не просто не могут даже V>месяц самостоятельно работать, а их работу надо отслеживать каждые V>несколько дней. Я уже не говорю о самостоятельном выполнении проекта.
Вы сделали вывод без знания конкректных деталей- кому было предложено и были у него предпосылки на успех.
V>З.Ы. Ты извини, но тобой написанное больше характеризует тебя как V>"эффективного менеджера", как совет проанализируй свои действия как V>руководителя. Какие книжки почитай, по психологии той же, психологии V>коллектива.
Спасибо за совет, я конечно подумаю об этом. Но в текущий момент это мне не нужно. Сейчас у меня подчинненых = 0.
З.Ы. Раз Вы перешли на личность, моя оценка Вам — Вы делаете очень резкие выводы не даваясь в детали конкретной ситуцаии. Как бы тоже имеет смысл задуматься.
1/17/2014 5:48 PM, kostik78 пишет:
> З.Ы. Чтобы отсеять возможный вопрос, в данном примере я участвовал как > главный разработчик а не директор. И мой персональный фаулт в данной > ситуции был — я не учел возможные последствия для UI и не сказал об этом > своем начальнику.
Задним умом все крепки. Разработчик часто даже предположить не может
многие места, где что-то может отвалиться, особенно, если проект не из
3-х строчек кода.
Для этого и тестеры и руководство есть. Первые, что найти эти места,
вторые, чтобы принимать решения и ответственность.
Вина в той ошибке только на руководителе. Даже, если он тебе доверял
больше, чем своей жене, это никак не говорит о том, что ты не мог ошибиться.
1/17/2014 5:56 PM, kostik78 пишет:
> V>Потому что предлагать надо не всем, а только тем, кто способен > V>организоваться (организовать) и довести дело до конца. На это ты и > V>руководитель, чтобы знать, кто и что может, а кто и что не может. > V>Это все выясняется в процессе работы постановкой задач разного уровня и > V>отслеживание того, как человек их выполняет. > V>Есть море высококлассных программистов, которые не просто не могут даже > V>месяц самостоятельно работать, а их работу надо отслеживать каждые > V>несколько дней. Я уже не говорю о самостоятельном выполнении проекта. > Вы сделали вывод без знания конкректных деталей- кому было предложено и > были у него предпосылки на успех.
Нет, это не вывод — это всего-лишь описание моего жизненного опыта о
людях в нашей области (точнее вывод, но из моего опыта).
> З.Ы. Раз Вы перешли на личность, моя оценка Вам — Вы делаете очень > резкие выводы не даваясь в детали конкретной ситуцаии. Как бы тоже имеет > смысл задуматься.
Я знаю и делаю это сознательно, причем еще специально утрирую многие
моменты.
И от этого есть проверенный плюс — удается поднять градус обсуждения и
почитать интересные мнения. Злясь, многие начинают писать более
однозначно и четко, не прячась за фразами ни о чем.
K>О чень часто непосредственный исполнитель не знает всего скопа задачи и данный проект может быть частью чего то большого. Соответсвено решения могут приниматся странные на его взгляд.
А в чем проблемма в той или иной форме выдать ему эту недостающую информацию?
K>Иногда надо принять просто на слово. В конце концов если ты не доверяешь коллеге, своему менеджеру то что за причина оставатся в этой команде. Мой опыт что удачные тимы это где люди доверяют друг другу и верят на слово как бы банально это не звучало.
Доверие берётся само из воздуха? Доверие мутному человеку вчера пришедшему рассказывающему "Ты пойми, так надо, нам же виднее, но мы не можем сказать тебе почему"
K>Что и требовалось доказать. Что было бы не сказано или сделано, менеджер всегда "виноват" на rsdn. Честно говоря я другого не ожидал. Очень четко прослеживается данная линия в других ветках где заходит разговор про менеджеров.
И не на RSDN тоже. Это входит в его обязанности — проследить, выяснить. За это менеджер и получает свою зарплату. Другое дело что никакой менеджер не может быть на 100% настороже, и ругать его за каждую промашку — все равно что ругать инженера за каждый баг в закоммиченном коде.
, почему на исполнителей (разработчиков, инженеров и т.п.) делегировать ответственность малореально. Вкратце — у них нет рычагов влияния на процесс. Тех, что есть только у руководства.
Здравствуйте, enji, Вы писали:
E>Наткнулся на интересное
Прочитал полный текст и у меня один вывод — виноваты ВСЕ, кроме самого несчастного программиста.
Во-первых, за кадром остался руководитель программиста. По всей видимости, это тим лид. Судя по полной версии истории, он сам первоначально "разругался" с подрядчиком. Затем пошел "на попятную" и померился, но не смог убедить продолжить работу своего подчиненного — программиста.
По хорошему, вопросы "убеждения" выполнения технической части лежат именно на тим. лиде. Именно он должен доносить ТЗ до программистов, отстаивать свое видение решения проблемы и отчитываться перед менеджерами. Не справляется? Пусть выгоняет программиста и интергрируется с подрядчиком самостоятельно. Не может? Гнать "погаными тряпками" уже его и искать другого тим. лида.
Во-вторых. Как я понимаю, программист работает уже достаточно давно и именно поэтому ему доверили столь ответственную часть (интеграцию с продуктом, написанным сторонней командой). Если так, то вы ранее не знали, какой у человека характер и какой нужен к нему подход? Действительно, есть такой тип программистов, для которых надо ставить максимально сложные задачи с минимально трудоемкой интеграцией их модулей. Если он именно такой, то руководитель серьезно ошибся поставив его выполнять задачу по интеграции, где нужна гибкость.
В-третьих, может быть подрядчик действительно работает хреново? Если так, то почему бы не поговорить с программистом "по человечески" и не объяснить, что первую версию выпустим согласно первоначальному плану. Далее, после выпуска первого релиза, спокойно "переделаешь самостоятельно" и будем поддерживать уже твое решение. Судя по моему опыту, гораздо проще проект поддерживать своей командой. В противном случае, даже для любого минимального исправления приходится согласовывать ТЗ + обосновывать расходы "на фичу" перед руководством. То и другое крайне тормозит развитие проекта.
Здравствуйте, gandjustas, Вы писали:
SK>>Трудозатраты на тестирование внесены в смету проекта. Т.е. из опыта мы уже примерно знаем, что на тестирование модуля надо будет 50 часов. Трудозатраты на ревью в смету проекта я внести явно не могу, т.е. надо будет выдумывать какую-нибудь статью расходов. G>То есть вопрос только в том как назвать позиции в смете, а в остальном ревью таки выгоднее?
Вот тебе простой пример.
Самый обычный SQL запрос. На одной и той же базе данных в зависимости от настроект оптимизатора выполняется от 0.1 сек до 58 сек.
Найди ошибку при ревью
SELECT SUM(Art.ArtGfgGew * Bst.BstMg) AS AktMenge
FROM Art_T Art, Bst_T Bst, Te_T Te, Pl_T Pl, Be_T Be
WHERE Art.ArtKnzGfgOk = 1
AND Art.ArtKnzGfg = 1
AND Te.TeKnzGfg = 1
AND ( 1 = 0 OR Art.ArtKlaGfgLg = 952 )
AND ( 0 = 0 OR Art.ArtKlaGfgWass = 0 )
AND Pl.WmgeBeNam = 'LHR2'
AND Art.ArtId = Bst.ArtId
AND Bst.TeNamTrg = Te.TeNam
AND Te.PlNam = Pl.PlNam
AND Be.BeNam = Pl.BeNam;
Это обычный sql запрос для Oracle. ничего такого особенного в нем нет, но вот тупит. Этот запрос, кстати, был тоже проревьюен.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
SK>>>Трудозатраты на тестирование внесены в смету проекта. Т.е. из опыта мы уже примерно знаем, что на тестирование модуля надо будет 50 часов. Трудозатраты на ревью в смету проекта я внести явно не могу, т.е. надо будет выдумывать какую-нибудь статью расходов. G>>То есть вопрос только в том как назвать позиции в смете, а в остальном ревью таки выгоднее? SK>Вот тебе простой пример. SK>Самый обычный SQL запрос. На одной и той же базе данных в зависимости от настроект оптимизатора выполняется от 0.1 сек до 58 сек. SK>Найди ошибку при ревью
SK>Это обычный sql запрос для Oracle. ничего такого особенного в нем нет, но вот тупит. Этот запрос, кстати, был тоже проревьюен.
Сразу в глаза бросается:
1) Нечитаемые имена, семантика запроса не ясна
2) Непонятно где условия join, а где выборка
Оба фактора затрудняют дальнейший анализ.
А вообще review делается для проверки корректности и сопровождаемости кода, оптимизация совершенно другая область, там надо мерить. Поэтому надо для начала посмотреть план, а еще луче прямо на живой системе мониторить missed indexes или что там подобное у оракла.
Здравствуйте, gandjustas, Вы писали:
G>Сразу в глаза бросается: G>1) Нечитаемые имена, семантика запроса не ясна
По-немецки еще как читаемы. G>2) Непонятно где условия join, а где выборка
что там непонятного? Все видно.
G>А вообще review делается для проверки корректности и сопровождаемости кода,
Вот о чем я и говорил. Такое можно и нужно ловить ревью, а так же простые логические ошибки.
G>оптимизация совершенно другая область, там надо мерить. Поэтому надо для начала посмотреть план, а еще луче прямо на живой системе мониторить missed indexes или что там подобное у оракла.
Вот и это тоже я имел ввиду. Что ревью не добьешься оптимизации.
Самый лучший способ это комбинирование ревью и тестов, но в некоторых случаях (как в приведенном выше) — ревью практически ничего не даст. Особенно, если не очень разбираешься в предметной области.
Ну а так, индексов было наоборот слишком много, причем воспроизводится тупит этот запрос только если optimizer_mode установлен в Rule.
Здравствуйте, alexsoff, Вы писали:
SK>>AND ( 1 = 0 )
A>Прошу прощения за оффтопик, а что за странные условия 1=0, это оптимизация в оракле такая хитрая?
Такое обычно делают, чтобы выбрать только названия столбцов. Конкретно, что происходит в запросе х.з. — это надо у автора говнокода спрашивать, да и он уже скорее всего уже не знает. Вот для этого, в том числе, код-ревью и нужен, чтобы в продакшн не попал "совсем понятный, простой и очевидный запрос".
Здравствуйте, MTD, Вы писали:
MTD>Такое обычно делают, чтобы выбрать только названия столбцов.
АА вон как, я просто использую только ms sql,а там это делается через более очевидный оператор TOP 0
Здравствуйте, alexsoff, Вы писали:
A>Здравствуйте, SkyKnight, Вы писали:
SK>>AND ( 1 = 0 OR Art.ArtKlaGfgLg = 952 ) SK>>AND ( 0 = 0 OR Art.ArtKlaGfgWass = 0 )
A>Прошу прощения за оффтопик, а что за странные условия 1=0, это оптимизация в оракле такая хитрая?
Скажем так, один и тот же запрос используется для поиска суммы, скажем количества товара, в одном случае по одному критерию (ArtKlaGfgLg), а в другом случае по ArtKlaGfgWass.
Эти запросы сначала кладутся в xml файло, из этого xml для каждого запроса автоматом при постройки системы делается свой класс.
Т.е. можно было бы запрос разбить на 2, тогда было бы на 1 класс в C++ больше. Поэтому тут они ввели такую практику, что пишется один запрос и с помощью вот этих 1 = 0 или 0 = 0 отключается или включается то или иное условие.
В этом случае идет выборка по ArtKlaGfgLg = 952, условие ArtKlaGfgWass = 0 не проверяется.
В C++ коде вызов этого запроса выглядит примерно так
sqlBlaBlaBla oSql(... 1, 952, 0, 0);
в приницпе можно написать и так
sqlBlaBlaBla oSql(... 1, 952, 0, 34646);
в итоге из этого сгенерируется
AND ( 1 = 0 OR Art.ArtKlaGfgLg = 952 )
AND ( 0 = 0 OR Art.ArtKlaGfgWass = 34646 )
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>Сразу в глаза бросается: G>>1) Нечитаемые имена, семантика запроса не ясна SK>По-немецки еще как читаемы.
Даже по немецки это набор сокращений. ухудшает читаемость, никуда от этого не денешься.
G>>2) Непонятно где условия join, а где выборка SK>что там непонятного? Все видно.
Еще раз — смешение условий выборки и джоинов ухудшает читаемость. Для любого здравого человка сей факт очевиден.
G>>А вообще review делается для проверки корректности и сопровождаемости кода, SK>Вот о чем я и говорил. Такое можно и нужно ловить ревью, а так же простые логические ошибки.
А о чем ты говорил?
G>>оптимизация совершенно другая область, там надо мерить. Поэтому надо для начала посмотреть план, а еще луче прямо на живой системе мониторить missed indexes или что там подобное у оракла. SK>Вот и это тоже я имел ввиду. Что ревью не добьешься оптимизации.
А кто-то говорил что review помогает оптимизировать? Максимум можно какиенить антипаттерны обнаружить, не более того.
SK>Самый лучший способ это комбинирование ревью и тестов, но в некоторых случаях (как в приведенном выше) — ревью практически ничего не даст. Особенно, если не очень разбираешься в предметной области.
Не понял на основе чего ты сделал вывод. Тесты тоже не помогают оптимизировать. Ревью дает гораздо больше тестов, есть статистика на этот счет.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, SkyKnight, Вы писали:
SK>>Здравствуйте, gandjustas, Вы писали:
G>>>Сразу в глаза бросается: G>>>1) Нечитаемые имена, семантика запроса не ясна SK>>По-немецки еще как читаемы. G>Даже по немецки это набор сокращений. ухудшает читаемость, никуда от этого не денешься.
По-немецки нормально читается. я даже когда в эту контору только пришел и увидел эти сокращения понял о чем речь. К тому же есть документы как у них принято сокращать. В это плане читаемость не падает совершенно.
G>Еще раз — смешение условий выборки и джоинов ухудшает читаемость. Для любого здравого человка сей факт очевиден.
Там два условия выборки только, все остальное join и видно это невооруженным взглядом.
G>>>А вообще review делается для проверки корректности и сопровождаемости кода, SK>>Вот о чем я и говорил. Такое можно и нужно ловить ревью, а так же простые логические ошибки. G>А о чем ты говорил?
Я и говорил, что ревью поможет для проверки корректности с сопровождаемости кода. Чтобы в код не попадало типа if ( bIsSomethingNeeded.toString().Length == 4 ) ....
А так же неправильное использование операторов new и ошибки типа if (a = 1) ....
G>>>оптимизация совершенно другая область, там надо мерить. Поэтому надо для начала посмотреть план, а еще луче прямо на живой системе мониторить missed indexes или что там подобное у оракла. SK>>Вот и это тоже я имел ввиду. Что ревью не добьешься оптимизации. G>А кто-то говорил что review помогает оптимизировать? Максимум можно какиенить антипаттерны обнаружить, не более того.
SK>>Самый лучший способ это комбинирование ревью и тестов, но в некоторых случаях (как в приведенном выше) — ревью практически ничего не даст. Особенно, если не очень разбираешься в предметной области. G>Не понял на основе чего ты сделал вывод. Тесты тоже не помогают оптимизировать.
Тесты помогают найти вот такие неоптимальные места. Это разве не помогает?
G>Ревью дает гораздо больше тестов, есть статистика на этот счет.
А статистика, она такая статистика. У меня своя статистика, которая говорит об обратном.
Я уже какой раз говорю, что подходы комбинировать надо. Один подход не даст никакой эффективности.
Вот жаль у меня кода нет, а то я бы скинул исходники API для видео-регистраторов. Я бы посмотрел, как бы ты ревью этого кода делал, особенно если нет знаний в предметной области.
Здравствуйте, SkyKnight, Вы писали:
G>>Еще раз — смешение условий выборки и джоинов ухудшает читаемость. Для любого здравого человка сей факт очевиден. SK>Там два условия выборки только, все остальное join и видно это невооруженным взглядом.
Точно восемь условий джойна там? Можешь назвать два условия выборки по твоей версии?
Мне лично кажется, что концептуально там либо 3, либо 4 параметра джойна, в зависимости от того, чего же хотел добиться автор.
И соответственно, то ли 6, то ли 7 условий выборки.
Вот это условие (and Be_T.BeТam = Pl.BeNam) — оно что из себя представляет? Это джойн всех записей Be_T, или неоднозначно
записанное условие (and Pl.BeNam in (select BeNam from Be_T))?
Здравствуйте, _ABC_, Вы писали:
_AB>Мне лично кажется, что концептуально там либо 3, либо 4 параметра джойна, в зависимости от того, чего же хотел добиться автор. _AB>И соответственно, то ли 6, то ли 7 условий выборки.
5 или 6 условий выборки (в зависимости от) и 3 условия join. Я не много запутался, признаю. Забыл про эти параметры, которые "= 1"
_AB>Вот это условие (and Be_T.BeТam = Pl.BeNam) — оно что из себя представляет? Это джойн всех записей Be_T, или неоднозначно _AB>записанное условие (and Pl.BeNam in (select BeNam from Be_T))?
Оно тут вообще не нужно и уже удалено. Это можно игнорировать. Вообще это join, но это лишнее.
Ответ не тебе, а gandjustas: условия выборки и join не "перемешаны".
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, alexsoff, Вы писали:
SK>>>AND ( 1 = 0 )
A>>Прошу прощения за оффтопик, а что за странные условия 1=0, это оптимизация в оракле такая хитрая?
MTD>Такое обычно делают, чтобы выбрать только названия столбцов. Конкретно, что происходит в запросе х.з. — это надо у автора говнокода спрашивать, да и он уже скорее всего уже не знает. Вот для этого, в том числе, код-ревью и нужен, чтобы в продакшн не попал "совсем понятный, простой и очевидный запрос".
Это стандартно. Приходит кто-то смотрит пол секунды, объявляет кусок кода говнокодом и начинает это все оптимизировать, при этом не спросив у "долгожителей" конторы "а почему так, а не так?". И вот если после этого вопроса выяснится, что да, действительно, это говнокод, тогда можно его переписывать. Все остальное — убийство времени.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, SkyKnight, Вы писали:
SK>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Сразу в глаза бросается: G>>>>1) Нечитаемые имена, семантика запроса не ясна SK>>>По-немецки еще как читаемы. G>>Даже по немецки это набор сокращений. ухудшает читаемость, никуда от этого не денешься. SK>По-немецки нормально читается. я даже когда в эту контору только пришел и увидел эти сокращения понял о чем речь. К тому же есть документы как у них принято сокращать. В это плане читаемость не падает совершенно.
G>>Еще раз — смешение условий выборки и джоинов ухудшает читаемость. Для любого здравого человка сей факт очевиден. SK>Там два условия выборки только, все остальное join и видно это невооруженным взглядом.
Это лишь твое мнение, а факт остается фактом. Читаемость код гораздо ниже, чем могла бы быть.
Я кажется начал понимать почему ты так против ревью. Критика всегда плохо воспринимается программистами, ты не одинок.
G>>>>А вообще review делается для проверки корректности и сопровождаемости кода, SK>>>Вот о чем я и говорил. Такое можно и нужно ловить ревью, а так же простые логические ошибки. G>>А о чем ты говорил? SK>Я и говорил, что ревью поможет для проверки корректности с сопровождаемости кода. Чтобы в код не попадало типа if ( bIsSomethingNeeded.toString().Length == 4 ) .... SK>А так же неправильное использование операторов new и ошибки типа if (a = 1) ....
Корректность гораздо шире, чем "использование операторов new...". Ты о чем сейчас?
G>>>>оптимизация совершенно другая область, там надо мерить. Поэтому надо для начала посмотреть план, а еще луче прямо на живой системе мониторить missed indexes или что там подобное у оракла. SK>>>Вот и это тоже я имел ввиду. Что ревью не добьешься оптимизации. G>>А кто-то говорил что review помогает оптимизировать? Максимум можно какиенить антипаттерны обнаружить, не более того.
SK>>>Самый лучший способ это комбинирование ревью и тестов, но в некоторых случаях (как в приведенном выше) — ревью практически ничего не даст. Особенно, если не очень разбираешься в предметной области. G>>Не понял на основе чего ты сделал вывод. Тесты тоже не помогают оптимизировать. SK>Тесты помогают найти вот такие неоптимальные места. Это разве не помогает?
Каким образом? Тесты обычно гоняют на тестовом наборе данных, а неоптимальность может проявится только на продуктивной среде.
G>>Ревью дает гораздо больше тестов, есть статистика на этот счет. SK>А статистика, она такая статистика. У меня своя статистика, которая говорит об обратном.
У тебя по десятке проектов максимум, да и то вряд ли ты реальные цифры имеешь, а исследования есть по 18,000 (восемнадцать тысяч) проектов.
SK>Я уже какой раз говорю, что подходы комбинировать надо. Один подход не даст никакой эффективности.
Комбинирование ревью и тестов (если мы говорим о функциональных тестах) не поможет улучшить производительость.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, _ABC_, Вы писали:
SK>5 или 6 условий выборки (в зависимости от) и 3 условия join. Я не много запутался, признаю. Забыл про эти параметры, которые "= 1"
Так немудренно запутаться, когда запрос так написан.
Здравствуйте, SkyKnight, Вы писали:
SK>Это стандартно. Приходит кто-то смотрит пол секунды, объявляет кусок кода говнокодом и начинает это все оптимизировать, при этом не спросив у "долгожителей" конторы "а почему так, а не так?".
Ну ты же реально говнокод привел, даже сам запутался
. И еще дельный совет — если вы используете непонятные стороннему человеку, но рабочие решения, то опишите их в вики, а в коде напишите комментарий с ссылкой.
Здравствуйте, MTD, Вы писали:
MTD>И еще дельный совет — если вы используете непонятные стороннему человеку, но рабочие решения, то опишите их в вики, а в коде напишите комментарий с ссылкой.
Вообще лучше в таких случаях комментарии в коде делать, рядом с непонятным кодом.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, SkyKnight, Вы писали:
SK>>Здравствуйте, _ABC_, Вы писали:
SK>>5 или 6 условий выборки (в зависимости от) и 3 условия join. Я не много запутался, признаю. Забыл про эти параметры, которые "= 1" _AB>Так немудренно запутаться, когда запрос так написан.
Я же наизусть запросы не заучиваю Свое первоначальное сообщение не смотрел и забыл, что там больше условий выборки. Запрос нормально записан.
Сначала условия выборки, потом joins. А то ты иногда не путаешься в мелочах
Здравствуйте, SkyKnight, Вы писали:
SK>Сначала условия выборки, потом joins. А то ты иногда не путаешься в мелочах
Путаюсь, а как же. Но, ИМХО, запрос плохо написан. Легко допустить ошибку.
Да и неоднообразно это как-то, когда для одного вида джойнов идет одна форма записи,
а для других — другая. Или Оракл как старые версии SQL Server поддерживает всякие *=, =*?
Здравствуйте, gandjustas, Вы писали:
G>Это лишь твое мнение, а факт остается фактом. Читаемость код гораздо ниже, чем могла бы быть. G>Я кажется начал понимать почему ты так против ревью. Критика всегда плохо воспринимается программистами, ты не одинок.
Ну скажем так, если для 10 человек нормальная читаемость, а для одного нет, то что-то не так у одного.
G>Корректность гораздо шире, чем "использование операторов new...". Ты о чем сейчас?
Что ты еще под корректностью понимаешь? А то так можно сказать, что "все что угодно шире, чем ....."
G>Каким образом? Тесты обычно гоняют на тестовом наборе данных, а неоптимальность может проявится только на продуктивной среде.
Я же говорю, тесты проводятся на среде максимально приближенной к продуктивной. Т.е. настройки у системы, БД такие же как. Данные для тестов — это данные из продуктивной среды, которые у нас каждый месяц обновляются.
Так же сохраняются данные за последние 3 месяца, на всякий случай.
G>>>Ревью дает гораздо больше тестов, есть статистика на этот счет. SK>>А статистика, она такая статистика. У меня своя статистика, которая говорит об обратном. G>У тебя по десятке проектов максимум, да и то вряд ли ты реальные цифры имеешь, а исследования есть по 18,000 (восемнадцать тысяч) проектов.
Да хоть по сто восемьнадцать тысяч, статистика у меня все равно своя.
SK>>Я уже какой раз говорю, что подходы комбинировать надо. Один подход не даст никакой эффективности. G>Комбинирование ревью и тестов (если мы говорим о функциональных тестах) не поможет улучшить производительость.
Не понял про производительность, но в любом случае комбинированный подход отловит больше багов.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, SkyKnight, Вы писали:
SK>>Сначала условия выборки, потом joins. А то ты иногда не путаешься в мелочах _AB>Путаюсь, а как же. Но, ИМХО, запрос плохо написан. Легко допустить ошибку. _AB>Да и неоднообразно это как-то, когда для одного вида джойнов идет одна форма записи, _AB>а для других — другая. Или Оракл как старые версии SQL Server поддерживает всякие *=, =*?
В мире оракла не пишут обычно left join, right join, inner join
Да он поддерживает записи вида
a.tt(+) = b.tt
a.tt = (+)b.tt
1. Программист — приемщик работ и проекта? Замечательно. Вопрос, а чем занят менеджер? Видимо периодически капает программисту что-то типа: "давай скорей, сроки поджимают", и вся любовь. Такого менеджера либо на курсы регулярного менеджмента (если из бывших программистов, тестировщиков), либо нафиг из IT, если из т.н. "менеджеров среднего звена". Видимо, с понятиями: делегирование, ответсвенность и обратная связь не знаком и близко.
2. Программист берется все делать бесплатно? Во первых — зарплата+налоги, выплачиваемые компанией,+аренда площади и много чего еще — это уже далеко не бесплатно. Формулировка "сделаю за бесплатно" простительна программисту, он за финансы не отвечает. Не должен он отвечать и за отношения с подрядчиком, это работа менеджера проекта. Допустить ситуацию, чтобы программист занимался работой менеджера, и в силу своего рвения (собственного мнения), поссорился с подрядчиком, означает — менеджер ни хрена не делает и тупо спихнул свои обязанности на подчиненного. А теперь, когда ситуация хреновая, пытается спихнуть на него и свои факапы. Не выйдет. Ответственность делегировать нельзя. Если директор займет позицию такого менеджера и уволит программиста, то на месте программиста я бы сам на хрен ушел из этой конторы, поскольку программист, как ясно из повествования, за результат своей работы борется и готов работать целикомсамостоятельно. Он мотивирован на результат, в отличие от горе-менеджера.
3. Про проектную документацию, описывающую фронт работ подрядчика и правила приемки не спрашиваю, ее там нет. Иначе бы ссора с подрядчиком не случилась.
4. В работу подрядчика вложены инвестиции. В случае их невозврата инвестиций нормальный менеджер проекта отвечает за них, как правило, собственным карманом. Если это не так, то в компании проблемы, потому что вместо ответственного будут искать козла отпущения и терять деньги на неправильном управлении.
5. С точки зрения программиста, директор может быть неправым. Программист не знает того, что известно директору, и наоборот. Это как раз нормальная ситуация и разруливается заранее, а не в момент выяснения отношений. Менеджер должен уметь разговаривать и на языке заказчика (директора в данном случае), и на языках программиста и подрядчика. Он посредник между этими звеньями процесса. Не допускать по возможности "замыкания" элементов системы друг на друга — часть его работы. В противном случае имеем конфликт.
6. Конфликт уже случился, нужно его решать, а не отчитывать программиста, что у него не получилась работа менеджера. Тем более, что деньги уже вложены.
7. Классический порядок — термин придуманный горе-менеджером, чтобы оправдаться перед собой, программистом, но не начальством, увы
Здравствуйте, enji, Вы писали:
E>Наткнулся на интересное
E>Вкратце: E>
E>Есть проект, который уже пол года выполняет сторонняя ИТ-фирма подрядчик.
E>А программист Д – с нашей стороны приемщик работ, текстов и всего проекта.
E>Месяц назад они — наш программист и подрядчик поссорились.
E>Теперь программист решил всем назло, сделать всё самостоятельно с помощью одного своего помощника.
E>...
E>И я попробовал убедить программиста, предложив такой вариант:
E>1. Он остаётся техническим руководителем проекта, делает всё, что хочет.
E>2. Но он обязать принимать работы и дать возможность подрядчику работать в соответствии с ТЗ.
E>Позиция программиста:
E>Я же сам готов всё сделать. Это будет бесплатно и гораздо лучше, чем сделает подрядчик.
E>Нужно немедленно разорвать контракт с подрядчиком.
E>Тогда я (программист) берусь все сделать через месяц и совершенно бесплатно ( за зарплату), только ко мне никто не должен лезть и мешать.
E>...
E>Я говорю:
E>- Интересы предприятия определяет Директор. Это правильный путь. Если Директор определил, что надо работать с подрядчиком, то надо либо подчиниться, либо увольняться. Недопустимо и неправильно молча делать вид, что подчиняешься приказу, но на самом деле пытаться угробить работу подрядчика и продвинуть свою.
E>Программист говорит:
E>- Интересы предприятия в том, чтобы эффективно, качественно сделать проект. Директор просто ошибается, нужно ему доказать, что он не прав и убедить изменить решение.
E>Я отвечаю:
E>- Есть классический порядок, который надо придерживаться в работе. На этапе обсуждения можно и нужно спорить и доказывать. Но после того, как решение принято, нужно его исполнять. Его тоже можно обжаловать, но только параллельно с выполнением.
E>...
E>Вопрос классический:
E>- Что делать?
E>При условии, что надо через месяц сдавать проект и при условии, что хочется сохранить подрядчика?
E>Там еще более 300 комментов. Выжимка: E>* уволить программиста — не сдадим проект в срок E>* пойти на поводу программиста — не сдадим проект в срок + поощрение шантажа E>* убедить программиста работать с подрядчиком — не убеждается E>* выпереть программиста, повысить помощника — помощник не до конца в теме
E>Еще у eao197 есть развернутый комментарий на тему, почему "я начальник — ты дурак" иногда очень правильно E>
E>1. Ваш начальник сам получил недвусмысленные указания без каких-либо пояснений и объяснений.
E>2. У него больше информации. (которую он не хочет или не может сообщать вам)
E>3. Ваше мнение может стоить гораздо меньше, чем вам кажется.
E>4. Руководитель действительно может знать и уметь больше чем вы.
E>У Евгения кстати и парочка местных старожилов отметилась
E>А вы чего думаете?
