» » » » Брайан Фитцпатрик - Идеальная IT-компания. Как из гиков собрать команду программистов


Авторские права

Брайан Фитцпатрик - Идеальная IT-компания. Как из гиков собрать команду программистов

Здесь можно купить и скачать "Брайан Фитцпатрик - Идеальная IT-компания. Как из гиков собрать команду программистов" в формате fb2, epub, txt, doc, pdf. Жанр: Прочая околокомпьтерная литература, издательство Издательство «Питер»046ebc0b-b024-102a-94d5-07de47c81719, год 2014. Так же Вы можете читать ознакомительный отрывок из книги на сайте LibFox.Ru (ЛибФокс) или прочесть описание и ознакомиться с отзывами.
Брайан Фитцпатрик - Идеальная IT-компания. Как из гиков собрать команду программистов
Рейтинг:
Название:
Идеальная IT-компания. Как из гиков собрать команду программистов
Издательство:
неизвестно
Год:
2014
ISBN:
978-5-496-00949-2
Вы автор?
Книга распространяется на условиях партнёрской программы.
Все авторские права соблюдены. Напишите нам, если Вы не согласны.

Как получить книгу?
Оплатили, но не знаете что делать дальше? Инструкция.

Описание книги "Идеальная IT-компания. Как из гиков собрать команду программистов"

Описание и краткое содержание "Идеальная IT-компания. Как из гиков собрать команду программистов" читать бесплатно онлайн.



В современном мире разработки ПО успех программиста во многом зависит не только от качества кода, но и от его взаимодействия с другими людьми. В этой занимательной и ироничной книге раскрываются основные закономерности и шаблоны поведения, возникающие в команде разработчиков ПО. Рассматриваются основные роли каждого из участников коллектива, паттерны их поведения и примеры организации наиболее эффективного взаимодействия внутри команды программистов. Эта книга поможет вам оценить важность человеческого фактора в процессе разработки ПО и научиться выстраивать эффективно работающую команду для IT-проекта любой сложности.






В среде профессиональных разработчиков ПО критика почти никогда не бывает личной – обычно она высказывается с целью создать максимально хороший продукт. Тонкость состоит в том, чтобы вы и окружающие вас люди понимали разницу между конструктивной критикой творчества человека и открытых нападок на его характер. Второе бессмысленно – это проявление мелочности, которое не способно что-либо изменить. Первое же всегда помогает определить путь к совершенству и, что важнее всего, воплощает уважение: конструктивный критик проявляет внимание к другому человеку и хочет, чтобы он или его работа стала лучше. Учитесь уважать коллег и критикуйте их конструктивно и вежливо. Если вы действительно испытываете уважение к людям, то у вас будет стремление выбирать тактичные и вежливые фразы, а это навык, который приходит только с опытом.

С другой стороны, вам также необходимо учиться принимать критику. Это подразумевает не только скромность по отношению к собственным навыкам, но и доверие к тому, что другой человек искренне неравнодушен к вашим ключевым интересам (и интересам вашего проекта!) и не считает вас идиотом. Программирование – такой же навык, как и любой другой. Он совершенствуется с практикой. Если коллега указал вам на то, как можно усовершенствовать ваши приемы, то воспримете ли вы это как нападки на ваш характер и попытку унизить ваше достоинство? Надеемся, что нет. Аналогичным образом, ваша самооценка не должна быть связана с кодом, который вы пишете. Вы и ваш код – не одно и то же. Повторяйте это снова и снова. Вы и ваш код – не одно и то же. Вы должны не только сами поверить в это, но и заставить поверить в это ваших коллег по работе.


Не отождествляйте самооценку с качеством вашего кода


Например, при работе с коллегой, которому не хватает уверенности в себе, следует избегать фраз типа «Приятель, ты наделал ошибок в потоке команд этого метода. Тебе стоит воспользоваться стандартным шаблоном кода, как поступают все». Такая реакция состоит из нежелательных приемов: вы говорите коллеге, что он «наделал ошибок» (как будто мир состоит из черного и белого), требуете, чтобы он что-то изменил, и обвиняете его в том, что он создал нечто, идущее вразрез с результатами других людей (тем самым заставляя его чувствовать себя дураком). Скорее всего, вы вызовете у коллеги негативную эмоциональную реакцию и заставите его занять оборонительную позицию.

Вот более удачный способ выразить ту же самую мысль: «Приятель, я не очень хорошо понимаю поток команд в этой части кода. Может быть, с ним будет проще разобраться и работать в дальнейшем, если воспользоваться стандартным шаблоном?» Обратите внимание на то, как вы, проявляя скромность, ставите вопрос о себе, а не о нем. Он не совершил ошибку – вы просто не понимаете код. Предложение нацелено на то, чтобы вашей скромной персоне все стало ясно и, возможно, поспособствовало бы устойчивому развитию проекта в долгосрочной перспективе. Вы также ничего не требуете и даете коллеге возможность спокойно отклонить ваше предложение. Обсуждение не выходит за рамки кода и не касается чьего-либо достоинства или навыков программирования.

Ошибайтесь часто, учитесь и повторяйте

В бизнес-сообществе существует широко известная (и банальная) легенда о менеджере, который совершил ошибку и потерял 10 миллионов долларов. На следующий день он пришел в офис и стал паковать вещи. Услышав неизбежное приглашение в кабинет генерального директора, он поплелся туда и молча протянул директору лист бумаги. «Что это?» – спросил директор. «Заявление об увольнении, – ответил менеджер. – Я полагаю, что вы пригласили меня именно за этим». «Уволить тебя? – недоверчиво спросил директор. – С чего мне это делать? Я только что вложил 10 миллионов долларов в твое обучение!»[5]

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

Мы оба работаем в Google, и один из любимых слоганов нашей компании звучит так: «Неудача – это возможность». Многие понимают, что без периодических неудач невозможно быть достаточно прогрессивным и рисковым. Провал рассматривается как ценная возможность извлечь опыт и стать лучше перед очередной попыткой. В связи с этим часто цитируются слова Томаса Эдисона: «Если я нахожу 10 тысяч способов, которые не работают, я не терплю неудачу. Я не чувствую себя обескураженным, поскольку каждая неудачная попытка – это очередной шаг вперед».

Компания Google часто следует принципу «не прятаться в пещере до тех пор, пока совершенство не будет достигнуто» (который мы обсуждали ранее): как только результат может быть чем-нибудь полезен, он публикуется в черновом виде. На этом принципе основана работа Google Labs. Успехи и неудачи становятся явными очень быстро; это дает возможность команде программистов усвоить опыт, сделать повторную попытку и выпустить новую версию продукта в максимально короткий срок. У этого подхода есть недостаток: Google периодически становится объектом иронии за то, что продукты вроде Gmail больше четырех лет существуют только в виде бета-версии. Преимущество такого подхода в том, что компания может быстро маневрировать и адаптироваться, создавая потрясающие продукты за очень короткое время. Требуется определенная скромность, чтобы согласиться на демонстрацию несовершенного продукта пользователям, и определенная вера в то, что пользователи очень ценят ваши усилия и хотят наблюдать, как быстро вы прогрессируете.

Ключом к обучению на своих ошибках является документирование неудач. Записывайте «результаты вскрытия», как их часто называют в нашей профессиональной сфере. Особо позаботьтесь о том, чтобы документ о «вскрытии» не оказался бесполезным списком извинений и оправданий – это не его предназначение. Хорошие «результаты вскрытия» всегда содержат информацию о том, что было усвоено, и о том, что будет изменено в результате полученного опыта. Затем поместите «результаты вскрытия» на видное место и работайте над воплощением в жизнь обещанных изменений. Помните, что другим людям (как сейчас, так и в будущем) проще изучать надлежаще документированные неудачи и избегать их повторения. Не скрывайте свой путь – пусть он станет ярко освещенной взлетной полосой для тех, кто последует за вами!

Хорошо составленные «результаты вскрытия» должны содержать в себе следующую информацию:

• краткий отчет;

• хронологию проблемы – от ее обнаружения до исследования и разрешения;

• основную причину проблемы;

• оценку последствий и ущерба;

• список действий, направленных на немедленное решение проблемы;

• список действий для предотвращения повторения проблемы;

• сделанные выводы.

Выделяйте время на обучение

Синди была суперзвездой – инженером-программистом, который был настоящим мастером в своей предметной области. Ее повысили в должности до технического руководителя, круг ее обязанностей расширился, и она «выросла» для решения новых задач. Скоро она уже обучала своих коллег премудростям профессии. Она выступала на конференциях и быстро получила несколько команд под свое руководство. Все это время ей очень нравилось быть экспертом, но в какой-то момент ей стало скучно. Она перестала осваивать новые вещи. Новизна роли самого глубокого и опытного эксперта в аудитории исчезла. Несмотря на все внешние символы мастерства и успеха, ей чего-то не хватало. Однажды она пришла на работу и поняла, что ее сфера компетенции утратила прежнюю актуальность; люди стали интересоваться другими темами. Где же она сбилась с пути?

Давайте признаем, что здорово быть самым сведущим человеком в аудитории, а обучение других людей приносит определенные результаты. Проблема в том, что достигнув локального максимума в своей команде, вы перестаете учиться. А когда вы перестаете учиться, вам становится скучно, и однажды вы потеряете былую значительность. Очень легко войти в роль ведущего игрока, но лишь отказавшись от части своего эго, вы способны увидеть новый путь и открыть для себя новые направления. Это тоже связано с развитием скромности и желанием учиться, которое столь же сильно, как и желание учить. Периодически выводите себя из зоны комфорта; найдите аквариум, в котором плавают рыбы большего размера, чем вы, и бросьте вызов трудностям, которые они создадут. Вы окажетесь значительно счастливее в долгосрочной перспективе.

Учитесь быть терпеливым

Несколько лет назад Фитц занимался созданием инструмента, который конвертировал CVS-репозитории в Subversion (а впоследствии и в Git).

Из-за сложности RCS и CVS он периодически обнаруживал странные ошибки в некорректных RCS-файлах, которые успешно разрешались в CVS. Поскольку его давний друг и коллега Карл знал CVS и RCS весьма досконально, они решили работать над исправлением этих ошибок вдвоем.


На Facebook В Твиттере В Instagram В Одноклассниках Мы Вконтакте
Подписывайтесь на наши страницы в социальных сетях.
Будьте в курсе последних книжных новинок, комментируйте, обсуждайте. Мы ждём Вас!

Похожие книги на "Идеальная IT-компания. Как из гиков собрать команду программистов"

Книги похожие на "Идеальная IT-компания. Как из гиков собрать команду программистов" читать онлайн или скачать бесплатно полные версии.


Понравилась книга? Оставьте Ваш комментарий, поделитесь впечатлениями или расскажите друзьям

Все книги автора Брайан Фитцпатрик

Брайан Фитцпатрик - все книги автора в одном месте на сайте онлайн библиотеки LibFox.

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Отзывы о "Брайан Фитцпатрик - Идеальная IT-компания. Как из гиков собрать команду программистов"

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

А что Вы думаете о книге? Оставьте Ваш отзыв.