В этом посте я кратно расскажу о том, что было на шестом занятии курсов повышения ИТ-компетенций, которое состоялось 16.12.2010. Рассказ этот не будет очень длинным, т.к. записей с данной лекции у меня осталось немного. Видимо, я очень увлеченно слушал :)

В начале занятия нам было рассказано о том, сколько примерно людей нужно «просмотреть», чтобы принять в штат нужное число работников. Получилась своеобразная пирамида:

/\ 15 чел. – принято
__\ 25 чел. – прошли техническое собеседование
___\ х2 – сделали тестовое задание
____\ х4 – получили тестовое задание
_____\ х2 – прислали резюме

Итого, чтобы набрать 15 человек программистом нужно рассмотреть в той или иной степени приближения около 400 кандидатов!

Далее, было сказано несколько слов об особенностях коллективной разработки у программистов. В частности о том, что известная формула в том, что суммарная производительность работников больше, чем сумма производительности каждого отдельного работника, здесь не работает. Однако разделение труда в программировании все равно приносит плоды, и необходимо, чтобы создавать крупные проекты. Благодаря некоторой специализации, программист может существенно увеличить свою производительность в отдельной области и выполнять соответствующие задачи быстрее и качественнее своего «неспециализированного» собрата.

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

Следующим вопросом было «планирование работ внутри команды разработчиков». Здесь нам «поведали» о таком способе распределения работ, как «таблица навыков». Думаю, объяснять подробно, что это такое, не надо. Это просто табличка, в которой на против каждой фамилии работника, в соответствующем столбце, ставится «плюсик», если он владеет данным навыком, и «минус» — если нет.

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

Теперь пару слов о различных способах коммуникации. Здесь мы расставили их в порядке убывания эффективности. Вот что у нас получилось:

1. Устное общение
2. Skype
3. e-mail
4. icq

В конце лекции была упомянута система управления проектами MS Project.

На этом лекция закончилась и нам пожелали успешно доделать аттестационное задание и успеть сдать его вовремя.