Всё что здесь описано — это далеко не жизненный цикл программного обеспечения — это описание моделей работы с процессами по созданию программного обеспечения. При этом процесы которые идут после ввода ПО в эксплуатацию обычно обзывают «Эксплуатация» или «Поддержка» и никак не детализируют, а это далеко не тривиальные процессы, внутри них тоже могут быть вотерфольные модели или модели построенные на цикле Дёминга (это различные исправления, патчи, апдейты и т.д.)
Сам по себе жизненный цикл — это период времени, который начинается с момента принятия решения о необходимости создания чего либо и заканчивается в момент полного изъятия этого «чего либо» из эксплуатации. К сожалению об этом часто забывают и может получиться так, что жизненный цикл ПО таков, что при подготовленном плане продаж (и полном его соблюдении) продукт становится ненужным ещё до того как окупил затраты на разработку, что делает неуспешным сам проект разработки и как результат сам продукт (с точки зрения компании разработчика)
Как это нельзя. Реально из всех багов которые не диагностируются по крашдампу — это проезд по памяти, т.е. если один модуль у другого модуля испортил память в результате чего у второго съехал IP и мы получаем AV в чистом виде, который тяжело диагностируется. Но если присутствует именно ошибка в модуле, т.е. модуль сам полез туда куда не надо или вызвал функции API так, что систему стошнило, то всё легко определяется через разбор стека вызовов, который в крашдампе есть и достать его можно через команду "!analyze -v" в WinDbg.
Увы, но он выдает только инфу по самой исключительной ситуации без отображения стека приведшего к ней (а это часто очень нужно), да и у меня на Win7 x64 не открыл дампы (пользовательские минидампы)
Debugging Tools For Windows — можно скачать отдельно от SDK, это примерно 6Мб (может чуть больше, уже не помню). При этом есть версия x64, x86 и вроде Itanium.
По сути, чтобы годно разобрать крашдамп больше ничего не нужно. Вы просто увидите в каком модуле произошло падение и по какой причине (поймете что за драйвер всё ломает, чтобы его заменить), но можно также скачать файлы символов для своей операционной системы и тогда если падение было в виндовом модуле — вы узнаете в какой функции.
Кстати, не забываем про такие команды windbg как "!analyze -v" и ".ecxr", да и вообще хелп почитать стоит.
Автор топика просто ищет оправдание своему желанию не получать высшее образование.
А вот высшее образование, первое в технической области, а второе в менеджменте и финнсах — дают очень много, это и кругозор и тренировка решения различных задач (различные подходы к решению задач) и гибкость ума (тренированный ум лучше не тренированного)
А ещё я полностью несоглсен с опровержением тезиса о навыке научения, естественно научить программить можно и обезьяну, но дрессированную обезьяну научить легче.
И проиграли, кстати, из-за большой текучки кадров, т.к. человек долго в таких конторах не сидел и сваливал как только у него появлялся какой-никакой опыт. А контора от такого сотрудника получала мизерный выхлоп.
для консолидации перепишу стадии зрелости:
1. Отдел кадров
2. Отдел по управлению персоналом
3. Отдел по управлению человеческими ресурсами
4. Отдел по управлению человеческим капиталом
В принципе статья о стародавней вещи — о компетентности и копетенциях. У компании есть вакансия, для неё можно нарисовать круг её компетенций. Наемный работник который пришел в компанию имеет свой круг компетентности. и далее надо смотреть не только какую общую площадь занимают на пересечении круг компетенции и компетентности, но и какая площадь остается не занятой. Именно от большого размера области вашей компетентности которая не охватывается компетенциями вакансии и возникает синдром «меня не ценят». И решаться такой вопрос должен кадровой системой, ротацией, расширением зоны компетенций и т.п, т.е. за кадрами надо следить и грамотно их использовать.
В курсе управления кадрами, например, нам выделяли несколько ступеней зрелости кадровых отделов компании (перечислю от низших к высшим)
1. Отдел по управлению персоналом
2. Отдел по управлению человеческими ресурсами
3. Отдел по управлению человеческим капиталом
(вроде их было четыре, но какой-то промежуточный не могу вспомнить) А теперь поясню, незрелый кадровый отдел — это всего лишь механизм фильтрации (собеседования), регистрации (прием на работу) и удаления (увольнения) сотрудников. Следующей ступенькой зрелости отдела можно считать ступень, на которой сотрудники считаются не просто толпой народа на позициях а ценным ресурсом, именно тогда в компании начинает строиться система обучения и мотивации персонала. А высшей ступенью является управление человеческим капиталом, это стадия развития компании, когда руководство осознает, что напрямую cash in компании зависит от того какие в ней работают люди, с каким потенциалом и т.п. Такая компания кадры растит, развивает и старается как можно больше совместить компетенции позиций с компетентностями сотрудников.
P.S. Но оговорюсь, вышесказанное — это теория, на практике таких стадий в чистом виде хрен найдешь и меня тоже недооценивают :)
Отличная статья, плюсанул. Хорошее native описание типов начальников. Вполне попадающее и под стили руководства по И.Адизесу (можно глянуть тут: www.elarasoft.com/concepts/roles/)
А насчет «кто вы?» — чистых типов не бывает :) (или очень редко) но доминирующий тип в принципе всегда можно выделить.
Вы не руководитель, а я руководитель. Я вам асписал всё как человек который был и с одной и с другой стороны баррикад. И если человек на следующий день после выхода на работу начал писать код — это не значит что он полноценно вошел в команду. И это можно сказать о программистах разного уровня и ньюбах и профессионалах. В среднем полноценный вход в работу — это от 3 месяцев до полугода.
Думаю что определить прям всё-всё-всё нереально, это ваши риски старайтесь их прогнозировать оценивать и подстраховываться. В любом случае вы будете в проигрыше если лишний раз проверите контору на «вшивость» на практике.
А вы куда смотрели когда устраивались на работу?
Вы же сами соглашались на зарплату, вы могли сами узнать многое о работе от человека который вас собеседовал, а до этого могли поискать инфу в инете. Вы могли оценить офис компании, попросить сделать для вас экскурсию в отдел разработки (чтобы понять как там вообще люди работают) и вообще много чего. От того что вас так надували — не делает плюсов вашему резюме и вашему рассказу о причинах смены мест работы. Вся информация от вас подвергается сомнению.
вот и представь себе, ты руководитель бизнеса и нанимаешь себе в разработчика, это будет твой актив, и актив рисковый. И ты будешь десять раз думать, оправдает ли данный человек твои риски, потому как если ты вводишь человека в проект, то до момента когда человек будет полностью лоялен и от него будет 100% отдача — это от 3 месяцев до полугода. И ты будешь брать себе программера которому будешь платить деньги, будешь тратить время его коллег, тимлидов, пм-ов на то чтобы человек вошел в курс дела, изучил рабочую среду, изучил всю кухню отдела разработки, научился с ней работать, а потом сразу свалил? Не думаю.
Поставьте себя на место руководителя и вам станет понятно, почему не хотят брать «зайцев», которые прыгают из одной конторы в другую.
Кстати, в теории орг. поведения есть такой временной ограничитель — время которое один человек работает на одной должности в одной конторе, после которого человек начинает деградировать (как специалист), так вот в нашей с вами любимой IT сфере, в частности в программировании, я считаю что такой срок — 2 года. Дальше, либо растем в ширь (технолог, архитектор) либо вверх (тимлид, пм, руководитель отдела), либо меняем работу (т.е. меняем рабочую среду, коллектив, область деятельности).
Кстати, подобные задачи ещё могут задавать не для того, чтобы их решили, а для того чтобы посмотреть, как кандидат будет их решать. Насколько быстро он сдастся, сколько будет задавать уточняющих вопросов, как будет отстаивать свое решение и т.п.
Так что не чморите олимпиадников, мехматовцев, физтехов и иже с ними, по чем зря :)
Вот! В этом то и ошибка, ни в коем случае не рассказывайте об этом на собеседовании. Компаниям нужны люди лояльные, которые примут ценности компании и будут следовать курсу компании. Они вас нанимают не для того чтобы вы самоутверждались или реализовывали свои цели. Они вас нанимают чтобы вы решали «их проблемы», до ваших проблем, мечтаний и целей им до лампочки. Если вы видите для себя перспективу в какой-то компании, то вам следует делать всё, для того чтобы ваше начальство думало, что ваш путь развития параллелен пути развития компании. Ну а дальше, берите то что вам нужно и уходите.
Почитал резюме, год админства, полтора года работа программером в одной конторе, потом полгода фриланса, потом полгода ещё в одной конторе, потом 4 месяца ещё в одной конторе, и год в последней конторе. Я бы на собеседовании серьезно подошел к изучению вопроса «Почему меняете работу?» и «Почему ушли из компании ХХХ?»
Если ещё пойдете собеседоваться, то обязательно продумайте ответы на эти вопросы, попробуйте поставить себя на место интервьюеров и руководителей которые вас нанимают. Удачи!
Вы знаете, у меня сложилось впечатление, что вас взяли не из-за того что вы долго или не оптимально решали задачи, а из-за того что вы за 4 года сменили 5 мест работы. Я считаю оптимальным для программиста менять место работы каждые два года. И если я вижу на собеседовании кандидата, который часто менял работу ( 2 -7 месяцев) то это меня настораживает. Тут либо человек неусидчивый, конфликтный, не командный или ещё чего.
Сам по себе жизненный цикл — это период времени, который начинается с момента принятия решения о необходимости создания чего либо и заканчивается в момент полного изъятия этого «чего либо» из эксплуатации. К сожалению об этом часто забывают и может получиться так, что жизненный цикл ПО таков, что при подготовленном плане продаж (и полном его соблюдении) продукт становится ненужным ещё до того как окупил затраты на разработку, что делает неуспешным сам проект разработки и как результат сам продукт (с точки зрения компании разработчика)
По сути, чтобы годно разобрать крашдамп больше ничего не нужно. Вы просто увидите в каком модуле произошло падение и по какой причине (поймете что за драйвер всё ломает, чтобы его заменить), но можно также скачать файлы символов для своей операционной системы и тогда если падение было в виндовом модуле — вы узнаете в какой функции.
Кстати, не забываем про такие команды windbg как "!analyze -v" и ".ecxr", да и вообще хелп почитать стоит.
А вот высшее образование, первое в технической области, а второе в менеджменте и финнсах — дают очень много, это и кругозор и тренировка решения различных задач (различные подходы к решению задач) и гибкость ума (тренированный ум лучше не тренированного)
А ещё я полностью несоглсен с опровержением тезиса о навыке научения, естественно научить программить можно и обезьяну, но дрессированную обезьяну научить легче.
для консолидации перепишу стадии зрелости:
1. Отдел кадров
2. Отдел по управлению персоналом
3. Отдел по управлению человеческими ресурсами
4. Отдел по управлению человеческим капиталом
В курсе управления кадрами, например, нам выделяли несколько ступеней зрелости кадровых отделов компании (перечислю от низших к высшим)
1. Отдел по управлению персоналом
2. Отдел по управлению человеческими ресурсами
3. Отдел по управлению человеческим капиталом
(вроде их было четыре, но какой-то промежуточный не могу вспомнить) А теперь поясню, незрелый кадровый отдел — это всего лишь механизм фильтрации (собеседования), регистрации (прием на работу) и удаления (увольнения) сотрудников. Следующей ступенькой зрелости отдела можно считать ступень, на которой сотрудники считаются не просто толпой народа на позициях а ценным ресурсом, именно тогда в компании начинает строиться система обучения и мотивации персонала. А высшей ступенью является управление человеческим капиталом, это стадия развития компании, когда руководство осознает, что напрямую cash in компании зависит от того какие в ней работают люди, с каким потенциалом и т.п. Такая компания кадры растит, развивает и старается как можно больше совместить компетенции позиций с компетентностями сотрудников.
P.S. Но оговорюсь, вышесказанное — это теория, на практике таких стадий в чистом виде хрен найдешь и меня тоже недооценивают :)
А насчет «кто вы?» — чистых типов не бывает :) (или очень редко) но доминирующий тип в принципе всегда можно выделить.
Вы же сами соглашались на зарплату, вы могли сами узнать многое о работе от человека который вас собеседовал, а до этого могли поискать инфу в инете. Вы могли оценить офис компании, попросить сделать для вас экскурсию в отдел разработки (чтобы понять как там вообще люди работают) и вообще много чего. От того что вас так надували — не делает плюсов вашему резюме и вашему рассказу о причинах смены мест работы. Вся информация от вас подвергается сомнению.
Поставьте себя на место руководителя и вам станет понятно, почему не хотят брать «зайцев», которые прыгают из одной конторы в другую.
Кстати, в теории орг. поведения есть такой временной ограничитель — время которое один человек работает на одной должности в одной конторе, после которого человек начинает деградировать (как специалист), так вот в нашей с вами любимой IT сфере, в частности в программировании, я считаю что такой срок — 2 года. Дальше, либо растем в ширь (технолог, архитектор) либо вверх (тимлид, пм, руководитель отдела), либо меняем работу (т.е. меняем рабочую среду, коллектив, область деятельности).
Так что не чморите олимпиадников, мехматовцев, физтехов и иже с ними, по чем зря :)
Если ещё пойдете собеседоваться, то обязательно продумайте ответы на эти вопросы, попробуйте поставить себя на место интервьюеров и руководителей которые вас нанимают. Удачи!