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

Получается, что спасение утопающих – это дело рук [...]]]>

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

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

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

Исходные данные:

• Senior Developer.
• Профессиональная деформация.
• Небольшой опыт выступлений.
• Тема про которую должен узнать мир.
• Желание развиваться.
• Региональная айти-конференция GeekFest.
• Адекватный тренер.

Важные мысли:

• «В первую очередь важна эмоциональная составляющая.» – Чуди из ярр студии.
• «Никогда не читайте то что написано на слайдах. Никогда!» – Голодный подкастер.
• «Не надо считать людей за идиотов и все разжевывать, кому надо разберется или спросит.» – Голодный подкастер.
• «Технический доклад скучен и очень сильно сужает аудиторию. И большому количеству технических подробностей не место в хорошем докладе.» – Голодный подкастер.
• «Хороший доклад лежит на грани, между умным занудством и веселой чепухой.» – Я.

Итак, в один прекрасный день я встретился с одним голодным подкастером. И он сказал что надо. Кто если не я, что-нибудь расскажет и покажет на очередном GeekFest. Я стал отпираться и говорить, что я рассказываю очень скучно и нудно, и люди при этом засыпают. Но Родина в опастности! И кто если не мы. К тому же он сказал что над моим выступлением мы плотно поработаем. Как наивен я тогда был.

У нас был месяц на подготовку, и за первую неделю я должен был сделать презентацию. Чем я и занимался по вечерам после работы. В итоге через полторы недели получилась первая версия презентации. И мой тренер сказал что ее надо выкинуть, чуть менее чем полностью.

Основные замечания к первой версии презентации:

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

Кстати, первую версию презентации вы можете увидеть здесь.

В итоге мы поправили несколько первых слайдов, и он подробно рассказал мне все, что думает про остальные. И погоревав несколько дней, я начал делать вторую версию, которую закончил за полторы недели до доклада. По второй версии замечаний практически не было, лишь шрифт был немного кривой. Но и эту проблему я победил, в последней версии используется кошерный Gills Sans из MacOS.

В итоге получилось следующее.

Но хорошо. Перезентация – это одно, но без выступления она не имеет смысла. И за неделю до выступления мы договорились встретиться и потренироваться. К этому времени я должен был написать и потренировать выступление сам. Чем я занялся, и даже написал речь на две с половиной страницы текста. И даже немного ее проговорил.

Первую версию моей речи можно найти здесь.

Итак, ровно к 12 часам солнечного воскреченья, я прибыл к голодному подкастеру в апартаменты. Целый час мы беседовали на филосовские темы. И ровно в час дня мы начали мою тренировку. Я рассказал свой доклад и это заняло ровно 19 минут. И по выражению лица тренера я понял что это фейл.

Основные замечания к первой версии выступления:

• Скучно и нудно.
• Очень много слов, которые затягивают слушателей в объятья морфея.
• Нет динамики в выступлении.
• Очень плохо проработаны переходы между слайдами.
• Нет ввода в тематику моей работы.
• Нет сопричастности.
• Очень слабо и вяло рассказано о проблемах.
• И еще много всяких замечаний.

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

Потом я был отправлен домой с наставлением все повторить и потренироваться еще раз в четверг по скайпу. Но в четверг мы того не сделали. Наверное я очень сильно утомил своего тренера и его уже мутило от моего доклада. Но я рассказал все своей жене и ей понравилось. Только она сказала что надо больше улыбаться, а то я какой-то мрачный.

И вот настал великий день – пятница! Конечно я волновался и переживал, но по моему скромному мнению у меня получилось. Но судит конечно вам, благо велась видеозапись и тут ее можно увидеть. Также вы можете посмотреть мое предыдущее выступление (оно скучно и немного нудно).

Несколько важных моментов:

• Рассказывать доклад одному человеку намного сложнее чем выступать перед большой аудиторией. Он тебя оценивает и может говорить болезненные гадости.
• Если вы волнуетесь перед презентацией, то можно воспользоваться волшебной фляжкой с успокаивающим напитком. Что я и сделал.

Ссылки:

• Мое выступление.
• Мое предыдущее выступление.
• Первая версия моей презентации.
• Вторая версия моей презентации.
• Первая версия моей речи.
• Демонстрация которую я показывал на выступлении.
• Статья голодного подкастера о том как сделать хорошее выступление.
• Подкаст своими руками.
• Сайт GeekFest.
• Фотографии с мероприятия.
• Анонимный опрос для тех кто видел мое выступление.
• Задать мне анонимный вопрос.

Related Posts:

• Мой доклад на GeekFest про архитектуру ПО и unit-тесты
• Делу дело или мечты о захвате мира
• Фрэнк Герберт «Хроники Дюны»
• Айзек Айзимов «Основание»

Только прежде чем читать, учтите тот факт, что я работаю в области разработки приложений на Java, потому буду рекомендовать средства учитывающие данную специфику. Также учтите, что это [...]]]> Я имею довольно небольшой опыт работы в сфере разработки программного обеспечения (всего 6 лет), но я уже накопил ряд полезных и правильных практик, которые можно использовать при создании программного обеспечения.

Только прежде чем читать, учтите тот факт, что я работаю в области разработки приложений на Java, потому буду рекомендовать средства учитывающие данную специфику. Также учтите, что это пока черновик, и ваши замечания (в том числе по орфографии и пунктуации) будут полезны

• В конце рабочего дня подведение краткого итога, и письменный ответ на три вопроса: что было сделано, какие проблемы возникли, что планируется сделать. Также неплохо предоставить данную информацию всей команде (электронная почта, внутренний блог), и если у них будет интерес, то они могут прочитать данный отчет. Полезность данной практики неоценима, каждый кто составляет отчет задумывается в конце дня над вопросом: а что он сегодня полезного сделал. И ради ответа на данный вопрос уже стоит использовать данную практику. Кстати, некоторые заметят что данная практика писутствует в Scrum методологии. Но я первый раз увидел ее на Иркутском Авиационном заводе, мне о ней рассказал один очень интересный человек.
• Все материалы по проекту должны быть сосредоточенны в одном месте. Например, ссылки на логи общения с заказчиком или URL, для репозиториев исходного кода. Порядок никогда не бывает лишним, а порой очень сильно способствует повышению производительности.
• Надо управлять требованиями заказчика. Что понимается под таким общим утверждением? Все просто, все запросы на изменея вносимые в проект от заказчика должны быть зафиксированны в электронном виде. В тяжелых случаях заказчик должен ставить подпись под каждым своим требованием. Да это бюрократия, да интереснее писать код, но без этого ваш проект имеет очень высокую вероятность провала. Хотя тут многое зависит от.
• После получения задания от заказчика надо объяснить своими словами что он хочет. Данная вещь очень важна, без нее очень часто реализовываются вещи которые хочет разработчик, а не заказчик. Хоть это и звучит дико, но тут надо искать компромис, ведь разработчик тоже не дурак и понимает к чему приведет реализация странных требований.
• Повесить на общее обозрение диаграмму описывающую архитектурные особеннности проекта. В идеале рядом с ней повесить диаграмму с ходом движения работ по проекту. Это позволит поднять уровень коммуникации между членами команды на принципиально иной уровень. Главное не забывать тыкать пальцем в элементы диаграмм при обсуждении проекта.
• Исходный код проекта должен хранится в системе контроля версий. Особенно это важно когда код пишет более одного человека, хотя я уже не представляю себе как можно писать код без системы контроля версий. Наверное у меня комплекс, но мне нужен хотя бы SVN для комфортной работы.
• Должна быть инструкция для настройки рабочего окружения по работе над проектом. Если данного документа нет, то получается истинный хаос при подключении нового человека в проект. Да и передача дел значительно затрудняется. Вики по проекту это идеальный вариант.
• Использование системы управления задачами. Наличие данной системы позволит более продуктивно исправлять различные проблеммы и не забывать про них. Не забывать это хорошо. Кстати, я рекомендую обратить внимание на Redmine.
• Наличие описания сборки проекта. Если каждый раз сборка проекта это череда магических пасов, и собрать проект может только единственный гуру в команде, то это бардак. Если будет описание процеса сборки приложения хотя бы в текстовом виде это значительно упростит работу работу всех членов команды, и избавит от ряда глупых вопросов. Идеальный вариант когда процесс сборки приложения автоматизирован (например при помощи Ant или Maven), тогда счастье разработчиков поистине безгранично.
• Разработка unit-тестов. Это очень противоречивая практика, иногда unit-тесты разрабатывать нецелесообразно, да и не все можно протестировать в рамках отведенного бюджета. Но когда unit-тесты есть и написанны правильно это очень сильно повышает уверенность разработчиков в устойчивости исходного кода. Тесты можно писать на JUnit.
• Использование системы непрерывной интеграции. Возможно вам это и не надо, но меня очень уж радует факт того, что каждый день происходит сборка системы, и возможно проходят все тесты. Это значительно повышает уверенность в разрабатываемой вами системе. Я рекомендую обратить внимание на системе непрерывной интеграции Hudson.
• С опаской относится к независящим от вас системам. Например ставить mvn-proxy репозиторий (я рекомендую Nexus), и пользовать его, а то вдруг глобальные репозитории упадут. Интернет ненадежная штука.
• Быть готовым к изменениям. Не все изменения одинаково полезны, но надо быть готовым принять разумные вещи и использовать их в своих целях. Я рекомендую использовать мозг.

Все вышеприведенные практики были полезны для меня лично и если они будут полезны вам, то я буду рад. Кстати, данные практики в основном описывают что необходимо делать для поддержки процесса программирования, но не затрагивают процесс планирования хода работ. Сам процесс программирования и полезные плюшки для него (например расслоение системы на уровни, использование шаблонов проектирования) я пока решил опустить, но к ним я еще вернусь

И напоследок: не забывайте думать, прежде чем делать!

UPDATE 2010-06-09: причесанная версия данного текста на хабре.

Related Posts:

• Тестирование Spring приложений. Транзакции в тестировании.
• Maven Repository Manager
• Мой доклад на GeekFest про архитектуру ПО и unit-тесты
• Импульс для Eclipse
• Эксплуататоры программистов в Иркутске. Взгляд со стороны программиста.

Все любят картинки, особенно их любят программисты. Но иногда взрослый контент утомляет, и интересно взглянуть на что то другое Поэтому все дружно смотрим на визуализацию различных алгоритмов, структур данных и тому подобное. Меня лично позабавила визуализация Красно-черного дерева (подробности из википедии).  Так что всем преподавателям программирования я рекомендую взять ресурс на заметку, и [...]]]>

Все любят картинки, особенно их любят программисты. Но иногда взрослый контент утомляет, и интересно взглянуть на что то другое Поэтому все дружно смотрим на визуализацию различных алгоритмов, структур данных и тому подобное. Меня лично позабавила визуализация Красно-черного дерева (подробности из википедии).  Так что всем преподавателям программирования я рекомендую взять ресурс на заметку, и показывать студентам красивые картинки

Related Posts:

• No Related Posts

Кстати, на мысли приведенные ниже, меня натолкнул пост Виктора Ронина – [...]]]> Заказчику никогда не понять Исполнителя, обратное тоже верно. А причина проста: вот Вы умеете читать мысли других людей? Я например пока не умею. Поэтому, ключевой момент для успеха проекта – это взаимопонимание между Заказчиком и Исполнителем. Но и тут не все так просто

Кстати, на мысли приведенные ниже, меня натолкнул пост Виктора Ронина – Реализация vs. Продукт и дальнейшее обсуждение данного поста.

Рассмотрим ситуацию: крупный системный интегратор автоматизирует деятельность маленькой компании, которая только начала свой путь в океане бизнеса. Они поймут друг-друга? У Заказчика хватит денег оплатить услуги Исполнителя? Я чаще всего вижу ситуацию когда для небольших Заказчиков все делают начинающие Исполнители-студенты. Они и денег просят немного и словами страшными не грузят. Вообщем налицо взаимопонимание, но вот результат оставляет желать лучшего.

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

Но мир не стоит на месте, и иногда Заказчик и Исполнитель развиваются И тут важно понимание обеими сторонами, что такое качественное и работающее программное обеспечение. Кстати, на эту тему неплохой пример привел Виктор Ронин, и я приведу написанную им аксиому:

Продукт = Реализация + тестирование + инсталяционный пакет + документация +  веб сайт+ реклама + маркетинг + поддержка + еще тьма всего.

Вообщем – “кролики это не только ценный мех”, поэтому стоимость разработки это не только стоимость разработки Есть еще поддержка, документация,интеграция… …и не каждый Исполнитель поймет Заказчика, обратное тоже верно

А каждому свое…

p/s
Картинка взята здесь: http://www.ljplus.ru/img4/a/r/arsenikum/leopold.jpg

p/s/s
Кстати вспомнился случай недопонимая с Закачиком: пять лет назад у нас был Заказчик из криминальной среды. И когда пришла пора платить, он нам сказал, что мы будем работать на него бесплатно и денег от него не будет. Мы тогда с большим трудом нашли адекватный ответ на его высказывания Денег он нам так и не вернул, но мы еще живы

Related Posts:

• Управление неизвестностью
• Черная дыра agile
• Заказчик и исполнитель. Жадность наказуема?
• Карго-культ в программировании
• Критерий качества кода

Основные моменты:

Кстати уже Прошла первая встреча Иркутского JUG и есть Фотографии.

На фотографиях даже есть я:)

Я

Моя презентация тут.

p/s Для тех кто в танке:

А ведь действительно, что делать если есть обстоятельства непреодолимой силы? Ставить оценку?А если тебя грозят уволить? Или убить?

Помниться у нас в вузе оценки даже ставили в обход преподавателей:) И преподаватели молчали и принимали это [...]]]> Довольно банальная проблемма. У человека есть знакомые, которые хотять просто так получить оценку по предмету. А человек принципиальный, по крайней мере вначале:)

А ведь действительно, что делать если есть обстоятельства непреодолимой силы? Ставить оценку?А если тебя грозят уволить? Или убить?

Помниться у нас в вузе оценки даже ставили в обход преподавателей:) И преподаватели молчали и принимали это как данность…

Помню когда я преподавал, то меня тоже пытались подкупить, например девушки просили меня позаниматься с ними дома, а молодые люди приводили плачущих мам. Но я тогда не сдался:) Хорошо хоть родственников я не учил:)

p/s
Для тек кто в танке: ссылка – http://www.rsdn.ru/Forum/message/3218388.aspx.

Related Posts:

• Бездари-лентяи и родственные связи… Часть 2:)
• Делу дело или мечты о захвате мира
• Не будите программиста!
• Перекресток
• Краткая модель работы Aptech-ИрГТУ и некоторые размышления

Цель курса: Научить студентов концепции веб-программирования? Аудитория курса: студенты 3 курса, знающие что такое программирование и ООП? Если предыдущие утверждения верны, то: