Здравствуйте, 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>Может быть, у вас какое-то другое представление о том, как надо улаживать конфликты, но по-моему конфликт считается улаженым тогда и только тогда, когда все стороны согласны с предложенным решением и сняли все свои претензии и возражения. В данной ситуации мнение программиста скорее всего было проигнорировано.
Давай я не буду пересказывать комменты из исходного поста? Если интересно — почитай.
Если нет, то домысливать не надо.
