Как я уже говорил ранее, качество решения с точки зрения производительности в коде заметить сложно. Разумеется, если мы видим использование кеширования, то резонно предположить что производительность повысится, а в случае сложных sql запросов – наоборот, понизится.
Однако эти предположения не всегда оправданы и уж тем более не могут дать какие-то количественные показатели, тобишь сказать насколько повысится или понизится производительность после внесения этих изменений.
На этапе разработки ясность вносят нагрузочные тесты. Не смотря на их синтетичность, при должном продумывании они в состоянии выдать неплохой прогноз об изменении производительности решения в реальной жизни. Однако синтетика остается синтетикой и надо оперировать реальными данными, вот только где и как их брать…
Если вы до сих пор считаете что внешний вид продукта не важен – то обратите внимание на рисунок и представьте что именно такую машину вам и подарили родители на день рождения. Если вы и после этого готовы делать такие “подарки” своим заказчикам, то оставшуюся часть статьи можно не читать.
Далеко не все продукты имеют команду дизайнеров и если вы пришли в небольшую компанию, то будьте готовы к требованию “эстетики” в ваших работах. Особенно это касается внутренних продуктов, где интерфейс постоянно меняется и говорить о каком-то дизайне там бессмысленно.
У словян есть такой забавный феномен – анализ чужого кода всегда заканчивается фразой “тут все надо заново переписать”. И это только пол-беды, ибо сразу после переписывания кода у другого программиста возникает ровно та же мысль – надо все переписать с нуля.
Забавляет меня этот феномен еще и тем, что когда начинаешь анализировать что же именно не понравилось человеку, то слышишь самые невероятные причины – неправильные отступы, имена переменных и прочий бред другие мелочи жизни.
Есть множество откровенно дурацких вопросов на собеседовании. Одним из них я долго считал “почему вы хотите работать в нашей компании?”. Причем не только я, это также было затронуто на хабре, и других сайтах, которые я сейчас уже не припомню.
В моем понимании, работодатель желал услышать деферамбы в свой адрес, ну или по крайней мере что-нибудь мега лестное. Обычно так я и готовился, когда шел на очередное собеседование. Но вот читаю шестую главу книги Брайана Трейси “Как нанять и удержать хороших сотрудников” и начинаю понимать что это за вопрос такой и что действительно хочет услышать в ответ работодатель.
Несмотря на то, что работа с людьми составляет немалую часть обязанностей менеджера проекта, непосредственно поиск и найм сотрудников явление достаточно редкое.
Стоит ли удивляться, что многие менеджеры воспринимают это как очередную проблему, которую нужно срочно решить. Наспех оформили вакансию, наспех провели собеседование и в бой… А через месяц-другой процесс может повториться, потому что ошиблись с предыдущим решением.
В этой заметке хотелось бы охладить пыл моих коллег-менеджеров и напомнить им о стоимости неправильного решения.
На досуге просматривал софт для учета кадров и среди статей Jobs.ua нашел весьма интересный пример креативного подхода к оформлению вакансии.
Чувствуется профессиональный подход. Автор не только четко разложил по полочкам обязательные и желаемые требования, но и шикарно расписал условия труда и разные бонусы.
Думается мне, что вакансия была закрыта довольно быстро, а нам остается учиться составлять подобные объявления…
Как по мне, так лучше бы ”Черная книга менеджера” не появлялась на свет и вовсе. Полезной информации мало, а противоречивость информации самой себе да и логике в целом настолько сильна, что пошла просто волна эмоций со стороны всех участников IT-процесса.
Впрочем, какая там волна, уже самая настоящая война, благо пока дипломатичная и конструктивная. И хотя лично мне в предыдущем посте конструктивности не хватило, ведь я пытался найти логику во всей это книге и не нашел, но были ведь и другие участники…
В 21 год мне представилась возможность занять место начальника отдела IT в отделении сбербанка где я проработал уже полгода. Но мне было отказано потому что я, кхм, слишком молод. И я сделал самую глупую ошибку, которую только мог сделать – я начал искать вакансии на стороне.
Нет, мой уход на другую фирму был вполне обоснован, все таки уж очень хотелось не админить, а программировать. Но если бы по уму, то кресло начальника отдела было бы мое.
И тут есть пара нехитрых рецептов, которые помогут в карьерном, и, как это не “пошло”, в зарплатном росте. Прочтение этих рецептов не отменяет походы на тренинги Саши Орлова, но дает хорошу отправную точку, которая вполне может стать достаточной для построения успешной карьеры.
Запущен космический корабль с Белкой, Стрелкой и чукчей на борту. Третий день полёта.
Вызывает Земля.
-Белка.
-Гав.
-Проверь показания синоптических приборов.
-Гав, гав.
-Стрелка.
-Гав.
-Проверь состояние растений на борту.
-Гав, гав.
-Чукча.
-Гав.
-Что гав?!?!?! Корми собак и ничего там руками не трогай.
К чему это я… Ах, да. Имел удовольствие читать книгу Славы Панкратова “Черная книга менеджера” и не могу не поделиться впечатлениями. Если кратко – такой массы противоречивых впечатлений у меня не вызывала еще ни одна книга.
Не секрет, что многие менеджеры вышли из программистов и зачастую видят решение текущих проблем именно скозь призму своего технического опыта, т.е. “сесть и написать самому”. Это порочная методика, имеющая массу негативных эффектов, но единственно возможная в некоторых случаях.
Если вам, не дай бог, предстоит побывать в такой ситуации, то вы должны четко представлять причины такого решения и, в первую очередь, уделять максимум времени для их ликвидации. Под катом мой жизненный опыт по данному вопросу.
Loading ...