K>Расскажите, пожалуйста, о том какие у Вас были типичные и авральные ситуации и о том, как вышли из них, как, по Вашему мнению, было бы правильно выйти из них.
Авральные ситуации — это головная боль для управлнецев.
Они должны их предупреждать и разруливать.
Программер же должен просто вовремя сообщать о надвигающихся проблемах.
bkat пишет:
> K>Расскажите, пожалуйста, о том какие у Вас были типичные и авральные > ситуации и о том, как вышли из них, как, по Вашему мнению, было бы > правильно выйти из них. > > Авральные ситуации — это головная боль для управлнецев. > Они должны их предупреждать и разруливать. > Программер же должен просто вовремя сообщать о надвигающихся проблемах.
Да, это наверное единственный хороший кейс для разработчиков:
накануне релиза (QA и UAT успешно прошли), глядя в (свой|чужой) код, вы
— (junior|middle|senior developer) | (team lead) случайно узрели там
полный пэ, который вам [не]понятно почему не проявился на тестировании,
но точно проявится в production и это будет (не слишком серьёзно, но
очень visible|очень серьёзно). Ваши действия?
kotenkamyr пишет: > > > Расскажите, пожалуйста, о том какие у Вас были типичные и авральные > ситуации и о том, как вышли из них, как, по Вашему мнению, было бы > правильно выйти из них. > Мне это нужно для того , что бы составить кейс для кандидатов.
Гарантировано отправить спецов подальше — вот к этому вы придете с таким
вопросом.
hrensgory пишет: > > Да, это наверное единственный хороший кейс для разработчиков: > > накануне релиза (QA и UAT успешно прошли), глядя в (свой|чужой) код, вы > — (junior|middle|senior developer) | (team lead) случайно узрели там > полный пэ, который вам [не]понятно почему не проявился на тестировании, > но точно проявится в production и это будет (не слишком серьёзно, но > очень visible|очень серьёзно). Ваши действия?
Во-во, мне именно твой ответ и хочется здесь увидеть.
Все эти раговоры насчет эффективности — обычное вешание лапши на уши и перекладывание с больной головы на здоровую... Есть основное правило гопников, когда они пытаются развести лоха — главное заставить лоха верить, что он виноват, возбудить в нем чуство вины, тогда он сам все отдаст... Когда начинаются такие разговоры — это значит — вас разводят, и неэффективность бизнеса и управления пытаются повесить на плечи программистов...
Здравствуйте, hrensgory, Вы писали:
H>накануне релиза (QA и UAT успешно прошли), глядя в (свой|чужой) код, вы H>- (junior|middle|senior developer) | (team lead) случайно узрели там H>полный пэ, который вам [не]понятно почему не проявился на тестировании, H>но точно проявится в production и это будет (не слишком серьёзно, но H>очень visible|очень серьёзно). Ваши действия?
Скажу — ну поздравляю, у Вас полная жопа — вот тут и тут...
Ну я пошел... мне пора идти на вторую работу, так как тут я зарплату не видел с июня...
Здравствуйте, hrensgory, Вы писали:
>> Программер же должен просто вовремя сообщать о надвигающихся проблемах.
H>Да, это наверное единственный хороший кейс для разработчиков:
H>накануне релиза (QA и UAT успешно прошли), глядя в (свой|чужой) код, вы H>- (junior|middle|senior developer) | (team lead) случайно узрели там H>полный пэ, который вам [не]понятно почему не проявился на тестировании, H>но точно проявится в production и это будет (не слишком серьёзно, но H>очень visible|очень серьёзно).
Довольно стандартная ситуация.
Переодически в нее попадаю.
H>Ваши действия?
Сначала иду к другому коллеге, с которым быстро обсуждаем проблему (мало ли, может я чего не так понял),
а потом идем к руководителю проекта. Сообщаем ему о проблеме и о том,
какие последствия это может иметь с нашей точки зрения, как технарей.
Далее PL обсуждает все это дело с PM, вовлекая все больших начальников, в зависимости от серьезности проблемы.
В итоге:
— либо принимается решение выпускать продукт, поместив в release notes, соответствующую запись
— либо сдвигается сроки...
В общем неприятно, но ничего страшного, если не гнать панику и не суетиться...
Здравствуйте, Uzumaki Naruto, Вы писали:
UN>Когда начинаются такие разговоры — это значит — вас разводят, и неэффективность бизнеса и управления пытаются повесить на плечи программистов...
Умение вовремя делать свою работу — это как раз важная штука для профи.
Другое дело, что на интервью про это действительно можно только навешать лапшу на уши.
Проверяется это только в деле...
B>Умение вовремя делать свою работу — это как раз важная штука для профи.
Это не вопрос эффективности отдельного программиста, а вопрос его проф. подготовности.
Да и опять же оценивать подобный скил можно только при условии профессионального и отвественного PM. В любой
компании всегда идет торговля между R&D и S&M (Sales & Marketing). S&M всегда для бизнеса "нужно вчера", "побыстрее" — их задача побыстрее продать, получить свой процент и двигаться дальше... И втакой ситуации если PM "слабый" и не может отстоять человеко-затраты подчиненных на ту или иную работу — то будут постоянно срывы сроков и овралы. Для ПМ, как и для программиста одним из важных качеств является умение трезво и объективно оценивать объем работ, свои (чужие) силы и возможности и уже после этого нести за них ответственность. Очень важным вкладом в эффективность является знание ПМ своей команды, умение грамотно делегировать полномочия... Зачастую лучшие ПМы это не те, кто самые крутые перцы перцы в программировании, а люди умеющие наладить личностно-рабочий контакт с ведущими разработчиками (именно специалистами), не стесняющиеся сказать "ты более лучший специалист в этой области чем я, ты лучше знаешь людей, по этому я тебе поручаю вести это направление, а тебе вот это" и задача ПМ грамотно координировать эти направления, координировать ведущих разработчиков.
Опять же если говорить об эффективности, важным фактором является мотивация — своевременная и четкая выплата заработной платы — что бы человек сосредотачивался на работе, а не думал — где бы стрельнуть сигарет или как он сегодня будет домой добирваться — опять прыгать через турникеты в метро и прочее... Очень важно обеспечение комфортной работы программисту (под этим я понимаю не про монторы, компьтеры, кресла, кофе и другое — это все второстепенно, а четкое, без ошибочное планирование работы, отсутствие незапланированных перекелючений между задачами, четкое ТЗ или налаженный контакт между исполнителем и заказчиком, доведение до понимания конкретным исполнителем, что он делает в общей системе (а не использование в темную), к чему его работа приводит на текущий момент. Крайне важна в эффективности слаженность команд и налаженность рабочих связей между отделами. Должна быть коммандная работа. в общем нормальная работа). Если все это обеспечить, эффективность будет максимальной.
Если убрать хоть один из элементов, эффективность будет экспоненционально падать... И никаким увещиваниями, повышением нагрузки и прочим эффективность не повысить — можно только её понизить и никакие увещивания, угрозы уже не помогут...
Здравствуйте, hrensgory, Вы писали:
H>Да, это наверное единственный хороший кейс для разработчиков:
H>накануне релиза (QA и UAT успешно прошли), глядя в (свой|чужой) код, вы H>- (junior|middle|senior developer) | (team lead) случайно узрели там H>полный пэ, который вам [не]понятно почему не проявился на тестировании, H>но точно проявится в production и это будет (не слишком серьёзно, но H>очень visible|очень серьёзно). Ваши действия?
Какие тут могут быть действия кроме как идти поднимать панику?
Но ни в коем случае об этом нельзя умолчать, даже если этот косяк твой
А вообще надо смотреть, точно ли оно проявится в production, при каких обстоятельствах, насколько они вероятны, что можно с этим сделать, можно ли какое-либо временное решение применить и если это действительно ошибка, то обязательно дополнить тесты, чтобы ловить этот вид ошибок. И только в зависимости от ответов на данные вопросы и от обстоятельств можно принять наиболее адекватное решение, либо забить временно, решить немедленно, применить временный фикс, отложить релиз, выпустить релиз, но после решить проблему в последующем патче, (не)предупредив кастомеров об ошибке, оторвать кому-то руки, сделать себе хараки... тьфу увлекся
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
H>>случайно узрели там H>>полный пэ, который вам [не]понятно почему не проявился на тестировании, H>>но точно проявится в production и это будет (не слишком серьёзно, но H>>очень visible|очень серьёзно). Ваши действия?
H>>- junior|middle
Показать синьеру или тимлиду проблемное место. Либо это неправильное понимание ситуации, либо раельная ж..а, которая эскалируется. H>>senior developer
Разобраться, насколько ж..а глубока, и показать тимлиду это место, с комментариями в каких случаях, по вашему мнению, это проявится, какие есть пути решения проблемы, и сколько они займут времени. H>> (team lead)
Аналогично синьеру разобратиься в серьезности и возможных способах и стоимости решения проблемы, и на пару с ПМ принять решение о дальнейших действиях, которые, надо сказать, зачастую зависят от политики компании а не от полноты ПЭ.
Y>Но ни в коем случае об этом нельзя умолчать, даже если этот косяк твой
+100!
-----
Любимая фраза физика-теоретика: "Вот видите, мы ошиблись всего лишь на порядок".
Vzhyk пишет: >> накануне релиза (QA и UAT успешно прошли), глядя в (свой|чужой) код, вы >> — (junior|middle|senior developer) | (team lead) случайно узрели там >> полный пэ, который вам [не]понятно почему не проявился на тестировании, >> но точно проявится в production и это будет (не слишком серьёзно, но >> очень visible|очень серьёзно). Ваши действия? > Во-во, мне именно твой ответ и хочется здесь увидеть. > > Мой ответ: зависит от ситуации.
Для _разработчика_ — нет, ответ не зависит от ситуации. Необходимо сразу
доложить об обнаруженной проблеме ближайшему из ответственных за релиз
(тимлиду или PM). При этом надо чётко осветить следующие вопросы:
— чем это грозит в production
— почему это не нашли тестировщики (если есть предположения почему)
— как это поправить, сколько времени займёт (если есть предположения как)
Все остальные действия — да, зависят от ситуации.
Чего не стоит делать:
— пытаться сначала исправить косяк, а потом уже докладывать т.к. время
дорого, а решение о судьбе релиза всё равно принимать не вам.
— в случае, если проект заказной, ставить в копию письма с изложением
проблем представителей заказчика. Это — зона ответственности вашего ПМ,
не стоит проявлять "ревность не по разуму"
Естественно всё это применимо только к компаниям с нормальным
менеджментом, где главное — результат а не "награждение непричастных и
наказание невиновных". Но есть ли смысл работать в других?
Здравствуйте, Uzumaki Naruto, Вы писали:
UN>-Очень важно обеспечение комфортной работы программисту (под этим я понимаю не про монторы, компьтеры, кресла, кофе и другое — это все второстепенно, а четкое, без ошибочное планирование работы, отсутствие незапланированных перекелючений между задачами, четкое ТЗ или налаженный контакт между исполнителем и заказчиком, доведение до понимания конкретным исполнителем, что он делает в общей системе (а не использование в темную), к чему его работа приводит на текущий момент. Крайне важна в эффективности слаженность команд и налаженность рабочих связей между отделами.
Эх...
Хочу так работать, причем чтобы это было не на бумаге для аудиторов, а на самом деле
Но в принципе я с тобой согласен. Проблема только в том, что и в описанной тобой идеальной фирме
найдутся те, у которых все равно будут проблемы с мотивацией.
Ну например, они будут чувствовать себя винтиками в отлаженном механизме.
А кто-то как раз будет себя более комфортно чувствовать в хаосе,
потому что ему в кайф приводить хаос в порядок.
На интервью по идее и надо пытаться понять, подходит ли работник фирме,
будет ли работник себя чувствовать в ней комфортно...
Кандидату конечно же тоже стоит оценить фирму со своих позиций.
Здравствуйте, Uzumaki Naruto, Вы писали:
B>>Эх... B>>Хочу так работать, причем чтобы это было не на бумаге для аудиторов, а на самом деле
UN>Мне повезло проработать в такой обстановке 3 года, перед этим 5 лет мучались с никчемными ПМами, недавно команду раздербанили...
А почему раздербанили?
Кто-то решил, что не очень эффективны или бизнес не прибылен?
Направление деятельности было не очень прибыльное... Хотя я отчасти не прав — команда цела, немного изменились внешние условия, сменилось направление деятельности, команда влилась в более крупный коллектив, где наш ПМ и деректора пытаются уже привить то хорошее, что у нас было.
hrensgory пишет: > > > Естественно всё это применимо только к компаниям с нормальным > менеджментом, где главное — результат а не "награждение непричастных и > наказание невиновных". Но есть ли смысл работать в других?
Стоит почитать хотя бы этот форум, чтобы убедиться, что компаний у нас с
нормальным менеджментом исчезающе мало, а вот таких "награждение
непричастных и наказание невиновных" — большинство.
И если удалось выявить оную ненормальность еще на собеседовании — это
хорошо — и этому нам помогают "хрюшки".
Здравствуйте, Alf, Вы писали:
Alf>Как показала практика, все количественные показатели по-большому гамбургскому счету бесполезны. Alf>Ну может кроме статистики открытых на девелопера багов и особенно процент переоткрытия после фиксов. Alf>Этого на собеседовании никто даже под страхом смертной казни не скажет =)
Вообще, чем больше человек делает, тем больше ошибок.
Поэтому у программиста, отвечающего за большой кусок функциональности программы, будет больше открытых багов, чем у того, кто делает малую часть работы.
