Проблема в том, что многие люди не понимают важность резюме. В принципе, ситуация на рынке такова, что мы готовы брать свежих выпускников университета или переучивать программистов других платформ. Но как можно брать на работу человека, который пожалел 30 минут на редактирование резюме? Там же требований минимум - не более 2х страниц, написанных 12-14 шрифтом, без ошибок. На первой странице должно быть представленно максимум полезной информации - как зовут, на какую позицию претендуешь, в каких проектах принимал участие и что именно делал. Если помещается - где работал и учился. А вот на второй странице можно писать уже навыки, курсы повышения квалфификации и парт-тайм проекты, если конечно все это соотносится к вакансии. Все! 2 страницы - МАКСИМУМ. HR-manager редко читает дальше строчки "желаемая позиция" и дальше перенаправляет резюме кандидата технарям из отдела где есть такая вакансия или требуется резерв вакансий. А технарей больше всего интересует __что конкретно_ делал человек и что он умеет. И возможно только директор предприятия вынося окончательное решение взглянет на строчку резюме что мол я такой хороший, не пью не курю и очень люблю домашних животных А то ведь понапишут такого... да еще и ТАК оформят... А кто такие технари? Люди вечно занятые, ну некогда им читать 124 страницы мелкого текста с кривыми полями... Поэтому резюме сразу идет в мусорку. Об этом кстати классно написал Joel Splolsky
Так что отправляйте резюме на рецензию как можно большему числу друзей и знакомым, правьте и вылизывайте - и только потом шлите в конторы!
comments wanted
Wednesday, March 28, 2007
Download direct from most video sites
Менеджер, аналитик, архитектор и все, все, все
Сегодня требовал от менеджера бизнес-модель проекта, на что получил предложение подойти и принять участие в ее составлении, на замечание, о том, что разработчик не должен делать бизнес-модели получил интересный ответ: "Ты пойми, аналитик, программист, архитектор это как строители на стройке. Кирпичи они одинаковые, так что, что ты принесешь кирпич, что аналитик, главное чтобы дом построился". На замечание, что аналитик, должен понять что надо строить, а архитектор донести, до тех кто таскает кирпичи, как надо строить, получил ответ, что у меня неправильные паттерны...
Я конечно могу ошибаться, но мне кажется, что для успешного проектирования и построения ИС должны соблюдаться некоторые условия:
1. Менеджер должен ясно представлять чем он руководит, и кто за что отвечает. Если менеджер видит систему только снаружи и представляет ее как дом из кирпичей, но при этом совершенно не задумывается о начинке этого дома и этапах его строительства, такого менеджера ждут сильные потрясения.
2. Совершенно необходимо при планировании любой задачи выделять время на ее грамотное документирование, а не пытаться сделать какое-то подобие документации в период сдачи проекта для отмазки.
3. Программисту необходимо ставить задачу, а не выгонять его в поле на вольные хлеба: как увидел, как понял, так и сделал, а потом переделал потому что не то увидел, а потом еще раз 20 переделал, потому что не так понял. Причем ставить задачу нужно грамотно, с очерченными границами.
4. При разработке ТЗ категорически необходимо опрределять четкие границы проекта, а так же цели проекта.
5. Ни в коем случае не надо говорить "Да" заказчику, стараясь ему угодить или заработать больше денег, не согласовав это с архитектором и аналитиком. Взвалив нношу не по лечам, можно потерять гораздо больше.
6. При разработке бизнес-модели крайне необходимо подробно описать все автоматизируемые процессы, всех участников, с описанием ролей, информационные потоки и структуру данных, подлежащих автоматизации и только после того, когда сложится ясная картина, приступать к построению системы.
Я конечно могу ошибаться, но мне кажется, что для успешного проектирования и построения ИС должны соблюдаться некоторые условия:
1. Менеджер должен ясно представлять чем он руководит, и кто за что отвечает. Если менеджер видит систему только снаружи и представляет ее как дом из кирпичей, но при этом совершенно не задумывается о начинке этого дома и этапах его строительства, такого менеджера ждут сильные потрясения.
2. Совершенно необходимо при планировании любой задачи выделять время на ее грамотное документирование, а не пытаться сделать какое-то подобие документации в период сдачи проекта для отмазки.
3. Программисту необходимо ставить задачу, а не выгонять его в поле на вольные хлеба: как увидел, как понял, так и сделал, а потом переделал потому что не то увидел, а потом еще раз 20 переделал, потому что не так понял. Причем ставить задачу нужно грамотно, с очерченными границами.
4. При разработке ТЗ категорически необходимо опрределять четкие границы проекта, а так же цели проекта.
5. Ни в коем случае не надо говорить "Да" заказчику, стараясь ему угодить или заработать больше денег, не согласовав это с архитектором и аналитиком. Взвалив нношу не по лечам, можно потерять гораздо больше.
6. При разработке бизнес-модели крайне необходимо подробно описать все автоматизируемые процессы, всех участников, с описанием ролей, информационные потоки и структуру данных, подлежащих автоматизации и только после того, когда сложится ясная картина, приступать к построению системы.
Wednesday, February 28, 2007
Subscribe to:
Posts (Atom)