Диалог произошел буквально сегодня:
- Скажи, как определить границы одного use case?
- В виде овала.
вторник, февраля 27, 2007
четверг, февраля 22, 2007
Ох уж эти цифровые технологии...
Постоянный информационный фон (можно так сказать?) о могуществе современных цифровых технологий порождает интересный феномен у простых пользователей: феномен завышенных ожиданий.
Вот свежая шутка, которую сегодня рассказал мне знакомый сисадмин.
Вот свежая шутка, которую сегодня рассказал мне знакомый сисадмин.
"Подходит ко мне наша пресс-секретарь (устроилась недавно) и просит перекинуть файлы какой-то пресс-конференции с диктофона на компьютер. Делаю, как просит, врубаю через колонки, чтоб удобнее расшифровывать было. В ответ недоуменный взгляд. На мое немое "???" ответ: -Мне не ЗВУКОВЫЕ файлы нужны, а WORDовские!!! -А как Вы себе представляете перевод звука в текст? (Ни "Dragona", ни "Горыныча" у нас нет) В ответ слышу гениальное:"Но ведь диктофон-то Ц_И_Ф_Р_О_В_О_Й!!! Значит можно КОНВЕРТИРОВАТЬ КАК-ТО!!!"
вторник, февраля 20, 2007
О кодере бедном замолвите слово.
Пост навеян недавним обсуждением в ITBlogs «До Бангалора вроде далеко, а программистов уже не найти» где обсуждалась проблема нехватки кадров и высказывались по этому поводу самые противоположенные мнения.
Я думаю, что отчасти IT компании сами усугубляют ситуацию. Часто на позицию, где достаточно было бы кодера стараются взять опытного программиста. Менеджеры идут на это сознательно, справедливо пологая, что лучше иметь чрезмерно квалифицированного специалиста, чем недоквалифицированного. Вот и пестрят HR сайты тысячами объявлений, всем требуются суперквалифицированные спецы с безумным перечнем скилов. А джуниоры никому не нужны.
Все это не правильно. Конечно, есть инновационные области, в которых нужны крепкие команды очень квалифицированных спецов. Но таких - меньшинство. Большая часть разработки ПО состоит в создании бизнес приложений по хорошо отработанным схемам, либо в адаптации уже существующих приложений к нуждам заказчиков. И вот здесь как раз и есть место для кодеров. Почему же всем нужны «специалисты с опытом работы от 2 лет» с внушительным перечнем скилов? Причины самые неприглядные. Например, на проекте из рук вон плохо с анализом требований, поэтому нужен опытный программист. Он с большей вероятностью сделает, то что требуется по нечетким устным описаниям, а в случае чего, быстро все переделает (в описании вакансии написано – способность работать в стрессовых ситуациях). Или на проекте плохо с проектированием. В этом случае квалифицированные программисты быстро переделают неудачный вариант системы. Т.е. в большинстве случаев опытные программисты нужны, для того чтобы компенсировать недостатки в управлении проектами.
По статистике, для проектов на платформе .Net кодирование занимает около 34% от общего времени проекта, тестирование 22%, проектирование – всего 7%, а анализ требований - около 10%. Остальная часть приходится на управление, документирование и прочие активности. Цифры для проектов на J2EE примерно такого же порядка. Таким образом, оптимально иметь в проектной команде на одного проектировщика и одного аналитика, пять кодеров и трех тестировщиков. Т.е. на двух специалистов высокой квалификации может приходиться до восьми человек начального уровня. Я участвовал в таких проектах и они были успешными.
Сама жизнь подсказывает нам решение проблемы кадрового голода. Сегодня студенты третьего курса устраиваются на позиции начального уровня (младший программист, тестировщик) и совмещают обучение с работой. К сожалению, к этому моменту основные курсы по специальности ими еще не пройдены, но уже ох как нужны в работе. К окончанию университета они имеют два года опыта работы и могут претендовать на более высокую позицию и зарплату.
Что мешает организовать двух уровневую систему подготовки программистов? Первый уровень - колледж, максимум два года, за которые человека надо обучить тому, что раньше называлось алгоритмизацией, т.е. умению писать код. Плюс углубленное изучение одной или двух платформ (.Net, J2EE, PHP). Наверняка не все захотят всю жизнь сидеть кодерами. Для таких, должен быть второй уровень - один, два года обучения и степень бакалавра или специалиста. Для тех, кто хочет развиваться дальше - магистратура, аспирантура и т.д. Естественно все это обучение должно проходить без отрыва от работы. Поэтому софтверным фирмам было бы выгодно группироваться вокруг крупных специализированных учебных центров.
Такой подход позволил бы нам равняться не на Бангалор, а на Стэнфорд и Беркли.
Я думаю, что отчасти IT компании сами усугубляют ситуацию. Часто на позицию, где достаточно было бы кодера стараются взять опытного программиста. Менеджеры идут на это сознательно, справедливо пологая, что лучше иметь чрезмерно квалифицированного специалиста, чем недоквалифицированного. Вот и пестрят HR сайты тысячами объявлений, всем требуются суперквалифицированные спецы с безумным перечнем скилов. А джуниоры никому не нужны.
Все это не правильно. Конечно, есть инновационные области, в которых нужны крепкие команды очень квалифицированных спецов. Но таких - меньшинство. Большая часть разработки ПО состоит в создании бизнес приложений по хорошо отработанным схемам, либо в адаптации уже существующих приложений к нуждам заказчиков. И вот здесь как раз и есть место для кодеров. Почему же всем нужны «специалисты с опытом работы от 2 лет» с внушительным перечнем скилов? Причины самые неприглядные. Например, на проекте из рук вон плохо с анализом требований, поэтому нужен опытный программист. Он с большей вероятностью сделает, то что требуется по нечетким устным описаниям, а в случае чего, быстро все переделает (в описании вакансии написано – способность работать в стрессовых ситуациях). Или на проекте плохо с проектированием. В этом случае квалифицированные программисты быстро переделают неудачный вариант системы. Т.е. в большинстве случаев опытные программисты нужны, для того чтобы компенсировать недостатки в управлении проектами.
По статистике, для проектов на платформе .Net кодирование занимает около 34% от общего времени проекта, тестирование 22%, проектирование – всего 7%, а анализ требований - около 10%. Остальная часть приходится на управление, документирование и прочие активности. Цифры для проектов на J2EE примерно такого же порядка. Таким образом, оптимально иметь в проектной команде на одного проектировщика и одного аналитика, пять кодеров и трех тестировщиков. Т.е. на двух специалистов высокой квалификации может приходиться до восьми человек начального уровня. Я участвовал в таких проектах и они были успешными.
Сама жизнь подсказывает нам решение проблемы кадрового голода. Сегодня студенты третьего курса устраиваются на позиции начального уровня (младший программист, тестировщик) и совмещают обучение с работой. К сожалению, к этому моменту основные курсы по специальности ими еще не пройдены, но уже ох как нужны в работе. К окончанию университета они имеют два года опыта работы и могут претендовать на более высокую позицию и зарплату.
Что мешает организовать двух уровневую систему подготовки программистов? Первый уровень - колледж, максимум два года, за которые человека надо обучить тому, что раньше называлось алгоритмизацией, т.е. умению писать код. Плюс углубленное изучение одной или двух платформ (.Net, J2EE, PHP). Наверняка не все захотят всю жизнь сидеть кодерами. Для таких, должен быть второй уровень - один, два года обучения и степень бакалавра или специалиста. Для тех, кто хочет развиваться дальше - магистратура, аспирантура и т.д. Естественно все это обучение должно проходить без отрыва от работы. Поэтому софтверным фирмам было бы выгодно группироваться вокруг крупных специализированных учебных центров.
Такой подход позволил бы нам равняться не на Бангалор, а на Стэнфорд и Беркли.
воскресенье, февраля 18, 2007
От искусства к индустрии, или Путь русского камикадзе.
Да простит меня Эдвард Йордон за заголовок, и все же: От чего у нас такие искусные программисты, и такая слабенькая индустрия ПО?
Как обычно на тему размышлений меня навело сообщение в форуме, на этот раз на Gotdotnet.ru “Командная разработка .net приложений.” Цитирую:
Дальше, во флейме, еще веселее. Оказывается, у них организация купила Microsoft Team Foundation Server (весьма дорогая, замечу, штуковина) и теперь никто не знает, что с ней делать.
В общем, сначала я посмеялся чуть не до слез. А потом до меня дошло, что ведь это проблема не только конкретного парня. Это проблема всей нашей отрасли.
Обратите внимание, автор вопроса вполне свободно оперирует такими понятиями, как «multi-tier архитектура» с одной стороны. А с другой стороны он совершенно беспомощен в вопросах касающихся организации процесса разработки. Сколько же у нас еще таких программистов, вполне на ты с последними технологиями, с блестящей математической и алгоритмической подготовкой, лабающих свой код, извините, на коленке. Вот представляете, какая силища пропадает! А руководителю даже в голову не пришло, что помимо закупки дорогостоящего TFS, в бюджет следовало заложить обучение людей работе с ним. Действительно, а зачем! Разобрались же они как то с multi-tier архитектурой, разбируться и с этим. Программисты у нас умные!
Так же было 15-20 лет назад, так и осталось сейчас. Помню, как делал первые свои программы «на заказ». Сам себе аналитик, программист и тестировщик. Поразительным и неприятным открытием для меня был тот факт, что пользователь в абсолютно «правильно» работающей программе, способен всегда найти какие ни будь ошибки. Помню как потом, придумывали способы разрабатывать программы в команде, интегрировать код, вылавливать и исправлять баги. В общем, наступали на все подряд грабли, изобретали заново все велосипеды пока не поняли, что весь этот путь уже пройден другими (ведь мы были и есть до сих пор в роли догоняющих, к сожалению). Что надо учиться делать софт, что это не искусство, а нормальная индустрия.
И что? Сегодня за своей спиной мы слышим стуки и крики – это следующие поколения русских программистов пробираются той же тернистой дорогой, и наступают на те же самые грабли, о которые когда-то набивали шишки мы. Многие скажут, красиво загнул, но неправда это. Сегодня уже все слышали о методологиях разработки, таких как RUP, MSF. XP, Agile и т.д., а некоторые их даже используют. Я сам был такого же мнения до недавнего времени. До тех пор пока не столкнулся с нормально поставленным процессом разработки в компании с CMM пятого уровня. После того, как прошел первый шок :), я стал по другому оценивать весь свой прежний опыт, равно как и опыт своих коллег. Загляните на форум посвященный работе и карьере на RSDN.ru, где народ делится, так сказать, производственными моментами: «можно ли править чужой код», «нужны ли архитекторы», «сдавали ли вы проект в срок», «как общаться с заказчиком». «как управлять программистами» (недавний опус на эту тему ), «как проходить собеседование». Многие темы и обсуждения свидетельствует о том, что большинство людей просто никогда в жизни не видели нормального поставленного процесса разработки, а вот негативного опыта имеют в достатке. Отсюда и все проблемы.
Но все же, за последние 10 лет в этой области прогресс на лицо. О чем свидетельствует хотя бы тот факт, что я работаю на компанию с CMM 5 уровня и рассуждаю сейчас на эту тему. И тут возникает вопрос:
А вот где совсем плохо, так это с продвижением сделанного на рынок. Вот уже господин Грызлов говорит: "Термин "русский программист" давно уже стал в мире узнаваемым брендом с прекрасной репутацией". А толку с того - чуть. Мы, конечно, все патриоты, и можем пересчитать все программные продукты, которыми прославилась наша отечественная IT индустрия. Но, согласитесь, странно, что страна со 140 миллионным населением, высочайшим уровнем образования, прекрасной национальной математической школой, вот уже второй десяток лет побеждает на всех программистских олимпиадах, и в тоже время не может выбраться из разряда догоняющих, а вернее - отстающих.
Порой мне кажется, что ничего не изменилось с тех времен, когда Леша Пажитнов написал свой Тетрис. С тех пор, тетрис разошелся по всему миру, а Россия, вместо экспорта программ, технологий и сервисов занялась массовым экспортом мозгов с силиконовую долину. Пресловутый «русский программист» стал узнаваемым брендом именно потому, что мы занимались экспортом мозгов. По своей сути процесс этот мало чем отличается от экспорта нефти, за исключением того, что мозги – ресурс отчасти возобновляемый. Вычерпали его еще явно не до дна. Несмотря на то, что темпы утечки мозгов в последние годы значительно снизились, до сих пор, крупнейшие корпорации, типа Microsoft, Samsung, etc., ежегодно устраивают выездные сессии в Москве по отбору и вывозу лучших из лучших. Тем временем внутренний рынок успешно заполнился западным программным продуктом, а отечественному разработчику достались только ниши обусловленные нашей национальной спецификой (типа бухгалтерского и банковского ПО). И все-таки рынок живет, дышит и развивается. Об этом говорит, например нешуточный кадровый голод, который испытывает отрасль уже не первый год. А это говорит о росте. Открываются R&D центры крупнейших западных компаний. Аутсорсы растут, как грибы после дождя. Код с комментариями на русском языке работает сейчас в Deutsche Bank и в Boeing, в Motorolla и в Intel. И пишут его (к счастью) теперь в Москве, Питере и Нижнем.
Массовый вывоз специалистов, воровство интеллектуальной собственности, как с нашей, так и с их стороны (Тетрис тому живой пример) были приметами первого, дикого этапа становления нашего IT рынка. Второй этап можно связать с массовым ростом сначала компаний офшорной разработки, а затем и R&D центров западных технологических компаний, а также с ростом рынка легального ПО и усилением борьбы с контрафактом. Мне кажется, не за горами третий этап. О его наступлении мы узнаем по массовому росту чисто Российских софтверных стартапов. Первоначально многие из них будут ориентированы на западный рынок, и возможно некоторые из них будут куплены крупными западными брендами. Внутренний рынок, наконец, подрастет до таких размеров, что позволит российским оффшорам работать не только на западных заказчиков но и на внутренних.
Может, будет и четвертый этап? Когда следующее поколение языков программирования, процессоров, или сетевых протоколов выйдут из стен Российских лабораторий и будут предложены мировому технологическому сообществу. Кто знает? Будем надеяться на лучшее, тенденция есть, мы ее видим. Иначе зачем все эти парни побеждают сейчас на программистских олимпиадах?
«Идем дорогой длинной, дорогой не прямой».
Как обычно на тему размышлений меня навело сообщение в форуме, на этот раз на Gotdotnet.ru “Командная разработка .net приложений.” Цитирую:
«Привет. Каким образом можно командно разрабатывать сложное приложение? Например используется multi-tier архитектура, то каким образом можно одновременно вносить изменения в программный код, скажем редактировать различные формы одно уровня представления несколькими людьми. Опыта такой разработки нет, почитал документацию по visualSourceSafe, но так и не понял, каким образом там поддерживается версионность.
Если не трудно, посоветуйте ПО, технологии, статьи. Спасибо.»
Дальше, во флейме, еще веселее. Оказывается, у них организация купила Microsoft Team Foundation Server (весьма дорогая, замечу, штуковина) и теперь никто не знает, что с ней делать.
В общем, сначала я посмеялся чуть не до слез. А потом до меня дошло, что ведь это проблема не только конкретного парня. Это проблема всей нашей отрасли.
Обратите внимание, автор вопроса вполне свободно оперирует такими понятиями, как «multi-tier архитектура» с одной стороны. А с другой стороны он совершенно беспомощен в вопросах касающихся организации процесса разработки. Сколько же у нас еще таких программистов, вполне на ты с последними технологиями, с блестящей математической и алгоритмической подготовкой, лабающих свой код, извините, на коленке. Вот представляете, какая силища пропадает! А руководителю даже в голову не пришло, что помимо закупки дорогостоящего TFS, в бюджет следовало заложить обучение людей работе с ним. Действительно, а зачем! Разобрались же они как то с multi-tier архитектурой, разбируться и с этим. Программисты у нас умные!
Так же было 15-20 лет назад, так и осталось сейчас. Помню, как делал первые свои программы «на заказ». Сам себе аналитик, программист и тестировщик. Поразительным и неприятным открытием для меня был тот факт, что пользователь в абсолютно «правильно» работающей программе, способен всегда найти какие ни будь ошибки. Помню как потом, придумывали способы разрабатывать программы в команде, интегрировать код, вылавливать и исправлять баги. В общем, наступали на все подряд грабли, изобретали заново все велосипеды пока не поняли, что весь этот путь уже пройден другими (ведь мы были и есть до сих пор в роли догоняющих, к сожалению). Что надо учиться делать софт, что это не искусство, а нормальная индустрия.
И что? Сегодня за своей спиной мы слышим стуки и крики – это следующие поколения русских программистов пробираются той же тернистой дорогой, и наступают на те же самые грабли, о которые когда-то набивали шишки мы. Многие скажут, красиво загнул, но неправда это. Сегодня уже все слышали о методологиях разработки, таких как RUP, MSF. XP, Agile и т.д., а некоторые их даже используют. Я сам был такого же мнения до недавнего времени. До тех пор пока не столкнулся с нормально поставленным процессом разработки в компании с CMM пятого уровня. После того, как прошел первый шок :), я стал по другому оценивать весь свой прежний опыт, равно как и опыт своих коллег. Загляните на форум посвященный работе и карьере на RSDN.ru, где народ делится, так сказать, производственными моментами: «можно ли править чужой код», «нужны ли архитекторы», «сдавали ли вы проект в срок», «как общаться с заказчиком». «как управлять программистами» (недавний опус на эту тему ), «как проходить собеседование». Многие темы и обсуждения свидетельствует о том, что большинство людей просто никогда в жизни не видели нормального поставленного процесса разработки, а вот негативного опыта имеют в достатке. Отсюда и все проблемы.
Но все же, за последние 10 лет в этой области прогресс на лицо. О чем свидетельствует хотя бы тот факт, что я работаю на компанию с CMM 5 уровня и рассуждаю сейчас на эту тему. И тут возникает вопрос:
Если вы такие умные, то почему такие бедные?
А вот где совсем плохо, так это с продвижением сделанного на рынок. Вот уже господин Грызлов говорит: "Термин "русский программист" давно уже стал в мире узнаваемым брендом с прекрасной репутацией". А толку с того - чуть. Мы, конечно, все патриоты, и можем пересчитать все программные продукты, которыми прославилась наша отечественная IT индустрия. Но, согласитесь, странно, что страна со 140 миллионным населением, высочайшим уровнем образования, прекрасной национальной математической школой, вот уже второй десяток лет побеждает на всех программистских олимпиадах, и в тоже время не может выбраться из разряда догоняющих, а вернее - отстающих.
Порой мне кажется, что ничего не изменилось с тех времен, когда Леша Пажитнов написал свой Тетрис. С тех пор, тетрис разошелся по всему миру, а Россия, вместо экспорта программ, технологий и сервисов занялась массовым экспортом мозгов с силиконовую долину. Пресловутый «русский программист» стал узнаваемым брендом именно потому, что мы занимались экспортом мозгов. По своей сути процесс этот мало чем отличается от экспорта нефти, за исключением того, что мозги – ресурс отчасти возобновляемый. Вычерпали его еще явно не до дна. Несмотря на то, что темпы утечки мозгов в последние годы значительно снизились, до сих пор, крупнейшие корпорации, типа Microsoft, Samsung, etc., ежегодно устраивают выездные сессии в Москве по отбору и вывозу лучших из лучших. Тем временем внутренний рынок успешно заполнился западным программным продуктом, а отечественному разработчику достались только ниши обусловленные нашей национальной спецификой (типа бухгалтерского и банковского ПО). И все-таки рынок живет, дышит и развивается. Об этом говорит, например нешуточный кадровый голод, который испытывает отрасль уже не первый год. А это говорит о росте. Открываются R&D центры крупнейших западных компаний. Аутсорсы растут, как грибы после дождя. Код с комментариями на русском языке работает сейчас в Deutsche Bank и в Boeing, в Motorolla и в Intel. И пишут его (к счастью) теперь в Москве, Питере и Нижнем.
Массовый вывоз специалистов, воровство интеллектуальной собственности, как с нашей, так и с их стороны (Тетрис тому живой пример) были приметами первого, дикого этапа становления нашего IT рынка. Второй этап можно связать с массовым ростом сначала компаний офшорной разработки, а затем и R&D центров западных технологических компаний, а также с ростом рынка легального ПО и усилением борьбы с контрафактом. Мне кажется, не за горами третий этап. О его наступлении мы узнаем по массовому росту чисто Российских софтверных стартапов. Первоначально многие из них будут ориентированы на западный рынок, и возможно некоторые из них будут куплены крупными западными брендами. Внутренний рынок, наконец, подрастет до таких размеров, что позволит российским оффшорам работать не только на западных заказчиков но и на внутренних.
Может, будет и четвертый этап? Когда следующее поколение языков программирования, процессоров, или сетевых протоколов выйдут из стен Российских лабораторий и будут предложены мировому технологическому сообществу. Кто знает? Будем надеяться на лучшее, тенденция есть, мы ее видим. Иначе зачем все эти парни побеждают сейчас на программистских олимпиадах?
четверг, февраля 15, 2007
Аццкий маркетинг 2. "Дело Поносова" закрыто.
В продолжение предыдущего поста. Известия только что сообщили о том, что "дело Поносова" закрыли "за малозначитьельностью".
Вот так, дело, получившее международный резонанс, закрывают не как нибудь, а "за малозначитьельностью". Бум закупок лицензий видимо теперь скоро сойдет на нет. Но зато есть надежда, что компьютерные классы в школах снова откроются.
А вообще, теперь есть тема, не ловить каждого по отдельности, а обложить всех у кого есть компьютеры (и вообще, хоть что нибудь есть) авторским сбором в 5%.
"Суд Верещагинского района Пермского края в четверг вынес постановление о прекращении уголовного дела в отношении директора сельской школы Александра Поносова, обвинявшегося в причинении материального ущерба компании Майкрософт на сумму 266 тысяч рублей.
Как сообщила рассматривавшая это дело судья Вера Баракина, уголовное дело прекращено в связи с малозначительностью. Поносов приобрел для своей школы в селе Сепычево компьютеры, оснащенные нелицензионными версиями операционной системы Windows."
Вот так, дело, получившее международный резонанс, закрывают не как нибудь, а "за малозначитьельностью". Бум закупок лицензий видимо теперь скоро сойдет на нет. Но зато есть надежда, что компьютерные классы в школах снова откроются.
А вообще, теперь есть тема, не ловить каждого по отдельности, а обложить всех у кого есть компьютеры (и вообще, хоть что нибудь есть) авторским сбором в 5%.
Всем бояться, или аццкий маркетинг.
Dmitri Kuzmenko пишет в своем блоге о цунами лицензирования, которое вызвано "делом Поносова". Всем стало страшно, все бросились покупать лицензии на софт. Закончится первый квартал, и дистрибутеры отрапортуют о сотнях процентов роста продаж, окончательно измученные менеджеры смогут наконец поменять свои "Форды" на "БМВ". Один районый прокурор смог сделать для рынка ПО больше, чем все визиты Била Гейтса. В Microsoft явно на такой оборот дела не расчитывали, и теперь хватаются за голову и не знают радоваться им или печалиться. Радуйтесь, глупые. "Welcome to Russia", как говориться. У нас даже поговорка такая есть - "боятся, значит уважают". В общем процесс становления цивилизованного рынка по русски пошел.
И только директора сельских школ еще долго будут вздрагивать при звуке слова Microsoft...
P.S. У ребенка в школе закрыли компьютерный класс. Все уроки информатики отменены на неопределенное время.
И только директора сельских школ еще долго будут вздрагивать при звуке слова Microsoft...
P.S. У ребенка в школе закрыли компьютерный класс. Все уроки информатики отменены на неопределенное время.
пятница, февраля 09, 2007
А вот вам гайд по безопасности.
Отличный обзорчик реального подхода к построению безопасного приложения в блоге Not a kernel guy. Скажу сразу, ничего нового (по крайней мере для меня), но главное что все в одном месте, доходчиво и всего на одной страничке. По каждому пункту можно писать отдельную статью (или книгу, или не писать а читать :), но это потом, а сначала - самая суть подхода.
понедельник, февраля 05, 2007
"Война - дело молодых" (с) В. Цой
Шикарная дискуссия развернулась на страницах Gazeta.ru Дискуссия между программистами и менеджерами. Хорошо что в online, в реале они бы уже наверное подрались. Это просто замечательный образчик войны стереотипов (для лучшего восприятия привожу обе части целиком, без купюр).
Итак, часть первая:
Итак это был замученный программист. А теперь, обиженный и нагловатый менеджер.
Я когда-то работал в компании, где все так и было. Программисты в своем кругу обсасывали менеджеров, а менеджеры между собой, примерно в таком ключе обсуждали программистов. И тогда я думал что это диалектика, закон природы такой, по Дарвину. Или по Киплингу: менеджеры есть менеджеры, а программитсы есть программисты. И вместе им никогда не сойтись.
Сейчас я понимаю, что просто в той компании был бардак. И такое положение вещей не редкость, к сожалению.
В своих филиппиках неправы оба. Однако, когда программист не особо разбирается в вопросах менеджента - это нормально, и простительно. Но когда менеджер не демонстрирует полное непонимание вопросов управления процессом разработки - это либо глупость либо провокация.
Нормальные методики разработки были придуманы, в том числе, и для разрешения подобных противоречий.
Сейчас я работаю в фирме где менеджеры не оценивают длительность проектов и никого не "нагинают", а программисты не выполняют работу тестировщиков и аналитиков. Где обучение программистов зарание планируется, равно как и обучение менеджеров. Не рай конечно, но я могу читать эти "мнения" просто с улыбкой. А вы?
Итак, часть первая:
Что думают программисты о менеджерах
Программисты учатся
Это процесс нельзя прерывать. Некоторые даже могут себе позволить менять работу для того, что бы набраться опыта (skills'а) в новых областях. А это означает, что прием на работу программиста со стажем не гарантирует, что он на 105% подходит вам. Он прошел собеседование. Он ответил на какой-то тест. Выполнил пробное задание. Ну и что? Тест и задание было придуман за пол часа до его прихода. Это задание даже может не относится к тому чем человек будет заниматься (любят всевозможные интеллектуальные тесты или алгоритмы поспрашивать). А собеседование проводили человек, которым назвать "гуру" может только программист на QBasic.
Часто прожект менеджеры поверхностно знакомы с теми технологиями, которые должны применятся в проектах.
Но они думают, что смогут оценить уровень программистов для приема на работу. Поистине детская непосредственность.
Они даже не задумываются, что их контора будет финансировать новоиспеченному сотруднику "глубинное бурение" в новые технологии. А человек поучится на вашем проекте и уйдет в другую контору. Там ему будут платить больше, так как другой менеджер по достоинству оценит его новые знания :) Из-за того, что квалификацию программиста трудно определить, некоторые работодатели уважительно относятся к различным сертификатам. И это, наверное, правильно.
Стартап для студента
Если вы менеджер то также должны понимать что, нанимая студентов не надо требовать скорости работы как у опытного программиста. Скорость будет ниже раза в 2-3. Они не тупые. Просто им тоже надо время на обучение. Вы также должны понимать, что хороший код у них появится только на 2-3 проекте. А когда вы счастливый сдадите их первый проект (который, разумеется, провалиться по срокам), то они, конечно, будут радоваться с вами, но и загадочно печально улыбаться. Они то понимают, что надо все переписать. Они, наконец, поняли, что построили не верную классовую структуру. Они теперь знают, как оптимизировать код (на форуме, за день до сдачи проекта, подсказали пару фишек). Могут улучшить его читаемость для дальнейшей разработки.
Но все это уже никак не влияет на ваш проект. Так что еще раз думайте при приеме на работу.
Оценка времениСкажите, как человек может точно оценить, сколько времени потребуется на проект, если он слабо понимает что предстоит делать. А прожект менеджер-уникум оценивает. Должность обязывает. Он составил ТЗ, разбил его составные части. Указал дидлайны и все. В бой.
Да он, конечно, посоветовался с программистом о времени.
Но через некоторое время программист узнает, что ТЗ это то, как видит систему заказчик и как понял все это ПМ. А вот жизнь и ТЗ это две разные вещи.
ТЗ поменялось. Сроки поменялись. А договор уже есть!!!! Надо как-то сделать в срок. Поздравляю, товарищ программист, будет работать у нас в выходные!
Выставляйте заказчику время в 2 раза больше запланированного (ну или хотя бы отталкиваетесь при переговорах). Это очень тяжко проходит, когда оплата почасовая, но, скорее всего вам столько времени и понадобится. При этом срок для программистов должен быть тот, который вы с ним утвердили. За слова надо отвечать. Но помните что отладка и багги - это естественный процесс. И если бы вы программировали вы бы это поняли : Будьте спокойны и относитесь к ошибкам философски. Рассчитать время отладки трудно, но это примерно 30 - 40% от всего объема работы.
Также не рекомендую оценивать время на глазок (о ну наши ребята такое писали!! Сделаем за месяц).
Мало однотипных проектов. Всегда есть свои тонкости. Страхуйтесь. Одно неверное слово менеджера - это неделя работы для программиста.
Любимый заказчик
Еще есть такая чудесная особенность заказчика, которую можно охарактеризовать фразой: "сам не знаю что хочу, но хочу". Т.е. что-то в шальной голове сформулировано, но довольно аморфно. Тут придется выезжать на место. Брать заказчика за шиворот и проводит допрос, похлеще гестапо.
Но это не означает, что все вам расскажут (по фильмам мы знаем: наши люди в гестапо молчали).
В конечном итоге все факты всплывут, но время… Время будет не на вашей стороне. Да, да… выходные. Держите заказчика на "коротком поводке". Опросили. Набросали ТЗ. Утвердили. Набросали GUI. Утвердили. Написали болванку-интерфейс без функционала. Утвердили. И т.д. Побольше промежуточных версий. Пусть заказчик чувствует ваш пот и кровь ;).
Делегирование обязанностей программисту
Я понимаю… у вас нет тестера, техпис уволился, аналитик заболел, дизайнер в творческом кризисе. Но с чего вы взяли, что программист выполнит их работу хорошо? Вы ведь не пытаетесь заставить всех этих людей программировать.
И еще совет ПМ'ам - больше учитесь. Хорошие прождет менеджеры так редки, потому что они должны быть программистами, психологами, финансистами, людьми с амбициями. А зачастую - это только люди с амбициями. Удачи.
Итак это был замученный программист. А теперь, обиженный и нагловатый менеджер.
Что думают менеджеры о работе программиста
Позвольте не согласиться и изложить как видятся некоторые пункты с точки зрения менеджера.
Учёба
Хотите учиться – учитесь! Но! – в свободное от работы время. Если Вас застукают с изучением, к примеру, Оракла, в то время как компания целиком и полностью работает на SQL Server – не взыщите, наказание будет жестким но справедливым – за разбазаривание времени и ресурсов компании на рабочем месте.
Оценка времени
Программист никак не может оценить время, потому что он не представлюет себе бизнес-процесс. Потому что заказчик платит не за удовольствие программиста кодить интересные кусочки, а за сделанную работу.
Заказчик
Простое железное правило: Нельзя выпускать программиста общаться с заказчикам. Никогда. Нигде. Во всяком случае, если ну очень нужно – только под контролем. Потому что душевная организация программсита ортогональна и неконгруентна целям бизнеса. Для программистов заказчик – это идиот с мешком денег, который даёт им возможность зарабатывать на жизнь, решая такие задачки, которые при других обстоятельствах программисты с неменьшим удовольствием решали бы бесплатно.
Делегирование
На самом деле программист может делать всё: и дизайн, и тестирование, и администрирование. Почему не делает? Ленив. Ему неинтересно.
Так что зачастую проблема менеджера – это не набрать новых людей, а заинтересовать, простимулировать (вариант: нагнуть) програмиста, чтобы тот выполнил требуююмую от него работу в рамках новой служебной обязанности.
P.S. Уважаемые господа программисты. Не тешьте себя иллюзиями: менеджер знает о программисте гораздо больше, чем сам программист. В том числе и то, что программист по природе своей ленив, но любопытен. Что хороший программист может работать и по 12 и по 14 часов в сутки, показывая сумасшедшую производительность.
Что любой проект может быть завершён за 1/2 отпущенного срока. Что для программиста лучший отдых – это смена рода (роли) деятельности. И самое главное – что нет уникальных, незаменимых программистов.
Именно за это сокровенное знание, а также за умение его применять, хорошие менеджеры получают зарплату в два-три раза больше хороших программистов. Ибо, ибо: мы с вами живём в мире людей, а не в мире компьютеров.
Соответсвенно, больше ценится тот, кто больше знает и умеет лучше управлять – кем? людьми, а не компьютерами.
Я когда-то работал в компании, где все так и было. Программисты в своем кругу обсасывали менеджеров, а менеджеры между собой, примерно в таком ключе обсуждали программистов. И тогда я думал что это диалектика, закон природы такой, по Дарвину. Или по Киплингу: менеджеры есть менеджеры, а программитсы есть программисты. И вместе им никогда не сойтись.
Сейчас я понимаю, что просто в той компании был бардак. И такое положение вещей не редкость, к сожалению.
В своих филиппиках неправы оба. Однако, когда программист не особо разбирается в вопросах менеджента - это нормально, и простительно. Но когда менеджер не демонстрирует полное непонимание вопросов управления процессом разработки - это либо глупость либо провокация.
Нормальные методики разработки были придуманы, в том числе, и для разрешения подобных противоречий.
Сейчас я работаю в фирме где менеджеры не оценивают длительность проектов и никого не "нагинают", а программисты не выполняют работу тестировщиков и аналитиков. Где обучение программистов зарание планируется, равно как и обучение менеджеров. Не рай конечно, но я могу читать эти "мнения" просто с улыбкой. А вы?
пятница, февраля 02, 2007
Vista: новые возможности - новые проблемы
Одна из новых фич Windows Vista - расширенные возможности голосового управления. В частности голосом можно выполнять команды ранее доступные только через shell, такие как запуск программ, перемещение и удаление файлов и т.д.
Это порождает невиданную ранее уязвимость. Теперь на компьютере с Vista можно воспроизвести аудиофайл который будет содержать деструктивные команды, и система выполнит их. Я думаю, можно обойтись и без записаных в аудиофайл хакерских команд, а воспользоваться, например Speech API и генерировать их "на лету".
Уязвимость действительно невиданная и экзотическая. Но по сути своей, это просто новый способ хорошо известного типа атаки "Elevation of privilege". Процесс, не имеющий привелегий выполнить деструктивный код, использует уязвимость - в данном случае аудио канал голосового управления, для того чтобы выполнить деструктивные действия. Почему это возможно? Потому что голосовое управление не способно валидировать и аутентифицировать свои входные данные - речевые команды. Все элементарно.
В обычном приложении когда, программа не проверяет данные вводимые пользователями - это дыра, прождающая все остальные уязвимости. Рассматриваемый нами случай - не исключение.
Таким образом, пока Vista не научится, как хорошая собака, определять по голосу своего хозяина, данная уязвимость останется.
Мне кажется, желание оснастить новый продукт коммерчески привлекательной фичей в очередной раз перевесило все остальные соображения, в том числе и безопасности.
Это порождает невиданную ранее уязвимость. Теперь на компьютере с Vista можно воспроизвести аудиофайл который будет содержать деструктивные команды, и система выполнит их. Я думаю, можно обойтись и без записаных в аудиофайл хакерских команд, а воспользоваться, например Speech API и генерировать их "на лету".
Уязвимость действительно невиданная и экзотическая. Но по сути своей, это просто новый способ хорошо известного типа атаки "Elevation of privilege". Процесс, не имеющий привелегий выполнить деструктивный код, использует уязвимость - в данном случае аудио канал голосового управления, для того чтобы выполнить деструктивные действия. Почему это возможно? Потому что голосовое управление не способно валидировать и аутентифицировать свои входные данные - речевые команды. Все элементарно.
В обычном приложении когда, программа не проверяет данные вводимые пользователями - это дыра, прождающая все остальные уязвимости. Рассматриваемый нами случай - не исключение.
Таким образом, пока Vista не научится, как хорошая собака, определять по голосу своего хозяина, данная уязвимость останется.
Мне кажется, желание оснастить новый продукт коммерчески привлекательной фичей в очередной раз перевесило все остальные соображения, в том числе и безопасности.
четверг, февраля 01, 2007
Наглядное объяснение разницы между Microsoft и Apple
Михаил Елашкин продолжает нас снабжать зарядом бодрости на весь день (картинки всем включить).
В чем разница между продуктами Microsoft и Apple? Лучше всего об этом расскажут их первые лица.
Microsoft - это вот что то такое:
А Apple - это ваще (в кадре Стив Джобс):
В общем, как справедливо заметил Михаил, видимо Apple все же покруче будет чем Microsoft.
В чем разница между продуктами Microsoft и Apple? Лучше всего об этом расскажут их первые лица.
Microsoft - это вот что то такое:
А Apple - это ваще (в кадре Стив Джобс):
В общем, как справедливо заметил Михаил, видимо Apple все же покруче будет чем Microsoft.
Подписаться на:
Сообщения (Atom)