Со времен регулярного наличия у нас студентов-стажеров, я выработала очень полезную привычку – не отметать никакие рекомендации. В последнее время я даже список себе составляю – потому что не все рекомендации воодушевляют бежать их выполнять – и вот они лежат, ждут своего часа.
В этот раз по рекомендации прочитала книгу «Джоэл о программировании» и это оказался очень интересный опыт. Книга выпущена в 2008 году на основе заметок из блога автора 2000-2003 годов – и местами выглядит мягко говоря устаревшей, и в основном это места о программировании – это может оттолкнуть. Собственно, эта часть вообще узкоспецифична – что еще ограничивает аудиторию, но книга то на самом деле гораздо больше про менеджмент! Про то, как программист Джоэл стал менеджером, познавая все прелести на своей шкуре и делая собственные выводы, и иногда все-таки читая литературу по теме, и написал об этом книгу). И не знаю, насколько сильным программистом являлся и является Джоэл, но к менеджменту у него определенно талант имеется.
Глава 20. Справочник бойца по проведению собеседования – это лучшая инструкция по интервью IT-специалистов, которая мне попадалась за многие годы!
И вот еще некоторые цитаты, которые запомнились (и во многих из них нашлось место метафорам – кстати более объемные объяснения через метафоры, которыми часто и метко пользуется автор можно найти в книге):
- Написание кода так же отличается от управления проектом, как нейрохирургия от выпекания кренделей. Нет никаких оснований полагать, что у блестящего нейрохирурга, каким-то образом попавшего на производство кренделей в результате некоего разрыва в пространственно-временном континууме, окажется хоть малейшее представление о том, как делать эти самые крендели, даже если он окончил Гарвардский медицинский колледж.
- Программисты и разработчики, углубляющиеся в написание кода без спецификации, считают себя крутыми гангстерами, стреляющими от бедра. Ничего подобного. Они просто крайне непродуктивно работают. Они пишут плохой код, создают дрянные программы и угрожают своим проектам, подвергая их совершенно ненужному риску.
- …если никто не читал спецификацию, то по завершении работы над продуктом возникает много споров. Кто-нибудь (из руководства, клиентов или из отдела маркетинга) восклицает: «Погодите, но вы же обещали сделать пароварку для моллюсков! Где она?» А программисты отвечают: «Никак нет, если вы заглянете в главу 3 спецификации, подраздел 4, параграф 2.3.0.1 , то увидите, что там прямо сказано – никаких пароварок для моллюсков». Но клиент этим не удовлетворяется, поскольку он всегда прав, и разозленным программистам приходится дополнительно оснащать продукт пароваркой для моллюсков (что делает их еще более циничными в отношении спецификаций). Либо менеджер заявляет: «Послушайте, в тексте этого диалогового окна слишком много слов, а еще в верхней части каждого диалогового окна должна быть реклама». Программисты в отчаянии: «Но ведь вы сами утвердили спецификацию, в которой точно указаны текст и расположение элементов каждого диалогового окна!» Разумеется, менеджер не читал спецификацию, потому что, когда он попытался это сделать, у него чуть не произошло размягчение мозга, и вообще во вторник он играл в гольф и у него не было времени.
- Одно из существенных различий между компьютером и человеческим мозгом состоит в том, что компьютер может спокойно ждать, пока вы определите термины, которые собрались использовать. Но человек не поймет без предварительных объяснений, о чем вы говорите. Человек не собирается что-то расшифровывать, он хочет читать по порядку и понимать. Человеку надо сначала показать общую картину, а затем уже расписывать детали. Компьютерную программу вы начинаете сверху и двигаетесь вниз, полностью излагая детали. Компьютеру безразлично, имеют ли смысл имена ваших переменных. Человеческий мозг схватывает идею гораздо лучше, если может составить живую картинку по вашему рассказу, даже если это лишь часть рассказа, потому что наш мозг эволюционировал так, чтобы понимать рассказы.
- Перемещая экономическую ответственность за ошибки на самих пользователей, вы лишаетесь даже ограниченных возможностей определить наносимый им ущерб.
- гораздо лучше отклонить хорошего кандидата, чем принять плохого. Плохой отнимет много денег и сил, а также время у других для исправления его ошибок.
- Как же определить, что этого человека надо принять? В принципе просто. Искать надо тех, кто: 1. Умен. 2. Доводит дело до конца.
- Помните, что «умный» и «знающий ответы на дурацкие вопросы» – это не одно и то же.
- Мы – программисты. Все программисты в глубине души – архитекторы, а первое, что хочет сделать архитектор, прибыв на строительный участок, – это выровнять его бульдозером и построить нечто грандиозное. Нас не воодушевляет частичная реконструкция: копаться, улучшать, разбивать цветочные клумбы.
- Если бы каждому молодому консультанту можно было загнать что-то в голову, просверлив ее сверхмощной дрелью со скоростью 2500 об/мин, то это было бы такое правило: Заказчики не знают, чего они хотят. Не надейтесь, что заказчики будут знать, чего они хотят.
- Все компании, предоставляющие услуги в ИT, становятся жадными и пытаются расти быстрее, чем могут находить талантливых людей, и начинают громоздить одни правила и процедуры поверх других, чтобы обеспечить «стабильное», если уж не блестящее, качество работы.
- Идеальный менеджер программы – это разработчик программного обеспечения, обладающий сочувствием к пользователям, организационными навыками и человеческими качествами лидера женского сообщества , и таких просто не найти в достаточном количестве.