Hi!

KP>уже говорили, но повторюсь, как ты начал с ведущего разработчика?

Нет. Начинал со стажера. Через полгода уже работал на равных в команде.
Еще через полгода мне поручили спроектировать новое приложение и организовать
работу команды.

DVL>>Вакансия: Руководитель проекта
KP>позицируеш себя как руководительно проекта, а акцент в резюме сделан на программирование.

Это больше техническое руководство, а не административное. Разумеется, я должен
разбираться в коде, который пишет команда, в работе тестеров, аналитиков, тех. поддержки.

Я знаю руководителей, которые вообще никогда не программили, но если нужно повысить
качество и надежность работы системы, быстрее и точнее удовлетворять требования
заказчиков, то чисто административные методы здесь мало помогут.

DVL>>Семейное положение: XX
KP>а кого это волнует?

Некоторые компании ищут только молодых и холостых, другие считают, что семейные
более ответственны.

DVL>>Языки и среды разработки: Borland C++, MS Visual C++, Delphi, MS Access, ASM
DVL>>(x86), VB 6.0, VBA, .NET (C#, VB, Managed C++), J2SE, JScript, VBScript.
KP>и ты ВСЕ ЭТО знаешь? или когда-то слышал и писал приложение класса Hello world?

Я все это когда-то использовал в работе. Понятно, что в одном проекте редко
используется все сразу. Но мне нетрудно поднять старые исходники и вспомнить,
если понадобится. Учитывая, что на позицию кодера я и не претендую. Скажем,
учить Smalltalk, Prolog, Lisp, Fort, Occam или что-то другое, на чем пишет команда,
мне придется дольше, т.к. на них я только Hello world писал. А из того, что я перечислил,
не вижу ничего удивительного. Эти языки похожи, как родные братья, и были довольно
распространены предыдущие 15 лет.

DVL>>Методики управления проектами: RUP, MSF, SCRUM, Agile.
KP>и ты готов ответить на вопросы по ключевым особенностям и различиям между RUP, MSF?

Вопрос интересный. Чисто академический. Я обычно использую разные элементы из разных
методик, и особо не задумываюсь (да и не помню), к чему что относится — к RUP или MSF.
В MSF есть такая стадия, как "стабилизация", а в RUP такой не описано. Можно весь
проект делать строго по RUP с оформлением всех документов, но понятие "стабилизации"
все равно возникнет само-собой. Ведь рано или поздно основная часть работы будет
заключаться не в добавлении новой функциональности, а в исправлении ошибок.
Соответственно, количество незакрытых багов пойдет на спад, опустившись до количества,
допустимого для выпуска релиза.

Мне кажется, что RUP как-то больше напоминает обоснованную научную теорию,
а MSF — больше похож на набор лучших практик (типа SWEBOK, PMBOK).
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73

Hi!

DVL>>>Методики управления проектами: RUP, MSF, SCRUM, Agile.
KP>>и ты готов ответить на вопросы по ключевым особенностям и различиям между RUP, MSF?
X>Это-то как раз несложно Я бы с большим удовольствием послушал о различиях между Agile & SCRUM =))

А сейчас Agile — что-то типа модного термина, который объединяет много чего. Туда и SCRUM можно
отнести и XP и есть даже понятие Agile MSF. В конце концов каждая контора создает свою собственную
методику, собирая ее из известных "кирпичиков", т.е. зарекомендовавших себя практик.
Очень многое в выборе методики зависит и от самой задачи, и от команды, и от руководства, и от заказчика.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73

Hi!

BZ>имхо, неинформативно. во-первых, почему начал с ведущего?

Не начал. Я уходил в должности ведущего. А если бы было одно
место работы? Так и писать "Junior"? Все 10 лет?

BZ>может, стоит добаить студенческий опыт раболты — тогда резуме будет выглядеть логичней?

Опыт студенческой я добавлял, когда писал резюме на юниора и другого опыта не было.

BZ>второе. список технологий в конце напоминает "карате, тэквондо..". как разработчик ты всеми этими
BZ>технологиями хорошо владеть не можешь, имхо.

Собственно, я на разработчика уже и не позиционируюсь. Да и не возьмут меня разработчиком.

BZ>по-моему, следует добавить в описание каждой работы использованные в ней технологии,
BZ>подробней рассказать о техзнической стороне продукта.

Да, нужен второй, более подробный вариант резюме, который высылать по запросу.
Техническая сторона продукта — не главное. Главное — удовлетворенность
заказчика и прибыль инвестора.

BZ>на длданный момент описания твоих работ выглядят чисто менеджерскими — исследовал,
BZ>руководил, продаём.

Из менеджерских там только координация работ и наладка бизнес-процессов "с нуля".
Аналитика в предметной области, проектирование системы, реализация одного из модулей,
внедрение, саппорт — это все разве менеджерские задачи? Собственно, я непосредственно
занимался всем, что касается проекта, кроме сейлза (т.е. поиска заказчиков).

BZ>да, размер руководимого коллектива имеет значение

Коллектив небольшой: два разработчика, два тестера, технический писатель,
саппорт. Собственно, не так много в стране проектов, которые требуют 10 и более
человек. Собственно, бюджет мизерный для проекта такого масштаба.

Помню, меня спросили, смогу ли я руководить коллективом в 50 человек.
Я спросил инвестора, найдет ли он деньги, чтобы два-три года на стартапе
оплачивать работу 50 человек. Меня в тот проект тогда не пригласили.
Проект оказался убыточным, инвестор пролетел на несколько лимонов баксов.

А я запустил проект, начиная всего с двух человек. И на этом направлении сейчас
в конторе работает более 20 (правда, не под моим непосредственным подчинением).
И проект приносит инвестору неплохие деньги.

BZ>подлумай сам, если бы ты искал руководителя коллектива ращработчиков — по каким
BZ>критериям бы ты его отбирал и впиши эту инфу в резюме

Не знаю. Не приходилось. Но я бы искал технически грамотного. Из бывших
разработчиков. Я вообще поклонник японского стиля руководства.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73