Архив за Декабрь, 2009

Кодировщик или разработчик?

Воскресенье, Декабрь 27th, 2009

Мне регулярно задают вопрос в чем, по моему мнению, отличия между программистом и разработчиком. В нашей профессиональной среде явна наличествует терминологическая путаница. Кроме того, похоже, что наша терминология не совпадает с американской.

Вот характерный пример дискуссии :

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

Смотреть, как непрограммист пытается управлять софтверной компанией — всё равно что наблюдать за новичком-серфингистом.
«Всё отлично! У меня на берегу отличные помощники, которые подсказывают мне, что нужно делать!» — говорит он и снова падает в воду. Типичное поведение администратора, считающего управление универсальной функцией.

Есть у меня серьезные подозрения, что коллеги на форуме под словом “программист” подразумевают инженера умеющего (пишущего) код и не делающего (не знающего) ничего, кроме написания кода. И именно поэтому коллеги с форума говорят, что человек, разбирающийся в системном и бизнес анализе, в архитектуре и верификации качества ПО на посту менеджера будет смотреться лучше кодера. Джоэл Спольски же явно под термином разработчик  имеет в виду в том числе и Гейтса. Который на описываемый момент имел отличные навыки системного и бизнес анализа, построения архитектуры ПО. И вполне возможно, что к этому моменту Гейтс не писал код уже многие годы.
Попытка увеличения производительности за счет узкой специализации сыграла с нами злую шутку. Но вопрос не в этом. Вопрос в том, что понимать под термином разработчик и что понимать под термином программист. Чем дальше, тем больше инженеры, именующие себя «разработчик/программист» отказываются от проектирования и создания GUI. От верификации и  анализа во всех его проявлениях отказ произошел еще раньше. Происходит постепенное выделение работ, связанных с разработкой БД в отдельную специальность. Но окончательно  добило меня известие о том, что ныне (в одной из фирм) инженеры, называющие себя «архитекторы» отказываются от разработки, верификации и описания API, отдавая это инженерам, именуемым «Системные аналитики». Себе “архитекторы” оставляют выбор языка реализации и написание кода. Как по мне, так это не совсем архитекторы. И не совсем разработчики. И даже не совсем программисты. А, скорее, обычные кодеры. Хорошая профессия. Без обид.

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

Пусть некая фирма занимается разработкой вебпортала. Основные виды работ:
aeoeaiinoe.png

Мое предположение:
1)    Те, кто занимаются только написанием кода – “кодировщики”
2)    Те, кто занимаются всеми или большей частью работ в секторе, выделенном пунктирной линией – “программисты”. Какой же программист не может проверить требования или свой собственный код? Это не программист. Это кодер.
3)    Термин “разработчик”. Здесь, пожалуй, самое сложное. На мой взгляд, под этим термином следует понимать всех людей выполняющих какие либо виды работ по разработке портала. А их отличие от обычных узкоспециализированных специалистов вроде кодировщика, аналитика, верстальщика, копирайтера – то, что они выполняют несколько видов работ.

Культура проектов. Проблема “Монтгомери-Паттона”.

Понедельник, Декабрь 21st, 2009

На семинарах довольно часто всплывает упоминание о трудностях взаимопонимания членов команды с разным культурным контекстом.  Приводят примеры о паттернах поведения индийских инженеров (нельзя высказывать критику в присутсвии руководителя), американских, русских, китайских. Как будто для недопонимания необходимо, чтобы участники общения были из разных культур! Мне вспомнился эпизод из книги О. Брэдли “Записки солдата” (смотри главу 9. “Вторжение в Сицилию”).

- Джордж, - сказал он, - позвольте мне дать вам совет. Если вы получаете приказ от группы армий, который вам не нравится, не выполняйте его. Я именно так и поступаю.

Монтгомери, конечно, шутил. Он сам был хорошим, хотя иногда и упрямым солдатом. Он выполнял полученные приказы, хотя порой казалось, что он обходил их, в то же время тщательно скрывая это. Совет Монтгомери Паттону, по существу, отражал обычную точку зрения британского командования, которую иногда трудно понять американскому солдату. В отличие от армии Соединенных Штатов, где требуется безусловное выполнение приказа, англичане рассматривают приказ как базу для дискуссии. Если возникнут разногласия, они принимаются во внимание, и в результате приказ может быть изменен. В американской армии, наоборот, мы стараемся предварительно выяснить все соображения, прежде чем отдавать приказ. После отдачи приказа его никто не может изменить, кроме командира, отдавшего его.

Если бы я знал об этой особенности англичан, я бы наверняка обратился к Паттону с просьбой опротестовать решение группы армий в отношении дороги.

Культуры США и Великобритании очень близки. Они говорят на одном языке. У них общие книги и фильмы. Во многом схожие учебники.  И в тоже время такая разница в культуре управления.
В описываемом эпизоде культурный барьер «Монтгомери-Паттона» привел к снижению темпов наступления (увеличение срока проекта) и неоправданно большим потерям (увеличение бюджета).
Несложно догадаться, что происходит, если сотрудники работающие над одним проектом не могут договориться договорятся о том, какую модель управления использовать. Вопрос не праздный. Ведь даже в застойные годы В СССР активно использовались минимум десяток различных моделей. Сейчас к этому добавляются западные и восточные модели. Причем, как разработанные у них, так и взятые у нас и затем адаптированные под себя. А уж проявление проблемы “Монтгомери-Паттона” даже в чисто российских командах встречается сплошь и рядом

PS. Кайдзен – это почти полностью советская разработка. Так по крайней мере говорят японцы.

Эффективность различных способов общения

Суббота, Декабрь 19th, 2009

В очередной раз увидев на слайде кастрированный график, решил восстановить справедливость. Вот так он выглядит у Коберна в книге  “Быстрая разработка программного обеспечения“:

d2.jpg

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

Очень рекомендую прочитать эту книгу перед тем как внедрять, а тем более адаптировать новую методологию в вашей команде. Вернее не так. Если у вас перед внедрением XP будет выбор чтения между Беком и Коберном, то читайте Коберна.
PS. Похоже в магазинах этой книги осталось всего ничего. Я бы на вашем месте поспешил.

Несколько условно разумных советов

Вторник, Декабрь 15th, 2009

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

Первая партия разумных советов:

  1. С какой стати платить сотруднику больше, чем по рынку? Разумно? Еще как!
  2. Нужны командные игроки. От тех, кто некомандный надо избавляться. Тоже разумно.
  3. Бизнес должен минимизировать расходы. Тут даже говорить нечего, как разумно.
  4. Бизнес принадлежит тому, кто платит бабло. Не просто разумно, но и понятно.
  5. Совершенно нормально и правильно резать косты. Т.е. избавляться от балласта, который хочет больше, чем приносит пользы сейчас. Прошлые заслуги никого не интересуют, бизнес живет сегодняшним днем. Архиразумно.

Представим себе, что некоторый человек, пусть это будет Вася, убедил инвесторов, что интернет стартап это круто и там можно поднять бабла. Или что IT это круто. Или что наноГЛОНАСо-Автовазо это круто. Или это инвестор нашел Васю. Неважно.

Важно то, что Инвестор дает денег. По $100 000 каждый месяц, в течение года. Не круто, но вполне жизнеспособно. В полном соответствии с советом #4, проект и фирма принадлежит инвестору. Рассмотрим два варианта развития событий.

Проект неуспешен. Есть еще один очень, очень разумный совет:

6.    Раз мы уже потеряли стока денег, то надо потерять еще немного. Вдруг кривая вывезет и этого слона без ручки можно будет продать.

Обычно после этого решения инвестиции еще продолжаются. Их могут порезать, могут наоборот увеличить, но еще на полгода – год агонии рассчитывать можно. Согласно #6, Васе нужно спрыгнуть с лодки через 14-18 месяцев после начала проекта. В этом случае он уходит сам, как руководитель нормального проекта. Будет тянуть – его уйдут и хорошо, если без записи последствий в трудовой книжке, а так же в грудной, но уже не книжке, а клетке.

Вариант второй. Проект успешен.

В этом случае те, кто стоял у истоков, почему то требуют к себе повышенного уважения в виде бесконечно растущего потока вечнозеленых шкурок невинноубиенных енотов. Совершенно непонятно, чего бы это (смотри #4)? Сочетание этих требований с  #3 и #5 приводит нас к еще одному разумному совету:

7.    Избавьтесь от тех, кто привел вас к успеху, сразу, как только найдете, кем их заменить.

Согласно #7,  Васе нужно спрыгнуть с лодки через 14-18 месяцев после начала проекта. В этом случае он уходит сам, как руководитель нормального проекта. Будет тянуть – его уйдут и хорошо, если без записи последствий в трудовой книжке, а так же в грудной, но уже не книжке, а клетке.

Но Вася то командный игрок! Он играет по правилам бизнеса и его цель как командного игрока –это получить через 14-18 месяцев максимально оплачиваемую новую работу в другой фирме. Дабы максимально соответствовать потребностям бизнеса Вася по крупицам выискивает разумные советы. В результате многолетнего мониторинга рынка труда (чтение текстов вакансий) его кладезь мудрости огромный, как барханы Сахары, пополняется следующим набором советных разумностей:

8.    Руководитель получает примерно на 30% больше, чем самый высокооплачиваемый из его подчиненных. Каждый новый уровень иерархии между должностью руководителя и нижним звеном увеличивает коэффициент.
9.    Бизнес ищет руководителей ранее занимавших аналогичные должности.
10.    Бизнес ищет руководителей руководивших N+ людьми.
11.    Бизнес НЕ ищет руководителей успешных проектов, приносящих от $500 000 в год в расчете на инженера. А нафига они? Истинная заслуга такого успеха естественно принадлежит тому, кто платит бабло. Смотри #4.

Ну, вы сами-то вакансии руководителей читали? На hh.ru там, или еще где.

Согласно ##8, 9, 10 и 11  Васе нужно в течение года подняться максимально высоко по иерархии и получить в подчинение максимальное число людей. Полагаю, это очень разумный вывод наемного работника из очень разумных советов владельцев бизнеса.

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

Естественно народу не нужна простая, примитивная как лопата и очень эффективная структура фирмы, где 4-7 инженеров непосредственно подчиняются Васе. Народу  нужно построить примерно следующее:

org.png

Уровней иерархий достаточно и многие хорошие, правильные люди получат хорошие правильные должности. Хорошо и правильно звучащие. И через год займут хорошо и правильно звучащие должности в других фирмах. А вот число сотрудников подкачало. Всего-то две дюжины. Но это легко поправить, если воспользоваться разумными советами. ##1 и 2.  При разумном подходе к кадровой политике на эти деньги можно нанять… До дюжины дюжин человек. Конечно, проект после этого гарантированно подохнет. Но Вася дал клятву беззаветно следовать разумным советам. Ради этого он готов даже пойти на жертвы. И даже пожертвовать каким-то проектом. Кому он вообще нужен то (смотри #11)?

Любопытный читатель может спросить: «Встречал ли автор примеры вышеописанного?» Здесь автор отсылает читателя к научной гипотезе о том, что в мире так или иначе всегда реализуется любая ситуация, при условии, что человек может ее себе вообразить. Кстати. Ситуации прямо противоположные вышеописанным точно встречаются. Ну и сами понимаете, что в зависимости от смены контекста разумные советы могут перестать быть разумными.

Онлайн-семинар “Как описать дефект”

Понедельник, Декабрь 14th, 2009

Буду проводить 24 декабря.

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

Основные темы:
• Как составить текст заголовка. Очень сложная тема, заинтересовавшая слушателей предыдущего семинара.
• Варианты описания воспроизведения бага
• Выбор грани между описанием симптомов и причины
• Тескт, скринкаст, видео. Что лучше?
• Борьба с лишними атрибутами бага.
• Одно описание или несколько? Одинаковые симптомы в разных местах.
• Когда нужно отказаться от BTS?

Почему на него стоит идти?
На тренинге будут рассмотрена основа основ работы тестировщика - описание дефектов. В литературе этого нет, на тренингах этот материал не дается (насколько мне известно). В тоже время тестировщика стажера (до года опыта), начинающего (до 4-5 лет) или ведущего тестировщика можно легко отличить друг от друга просто глянув на десяток заголовков дефектов.

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

Три причины не писать документацию

Вторник, Декабрь 8th, 2009

Первая. Документация не больно то и нужна.

Представим себе небольшую команду разработчиков, занимающихся автоматизацией машиностроительного завода. Часть софта покупают, часть пишут сами. Семен Владимирович пришел на завод работать программистом в 1981 году. Остальные в 1988, 1993 и 1997. Самый молодой из разработчиков работает в команде последние 12 лет. Понятно, что в таких условиях все разработчики прекрасно знают операционную среду, заказчиков, пользователей и код. И вся документация на новую фичу трудоемкостью в два человеко месяца может умещаться на одном стикере.

Я предлагаю три метрики:

  • Средний опыт разработчиков. В данном случае это 19+ лет.
  • Средний опыт работы вместе. (21+16+16+12+12+12)/6= 15 лет
  • Средний опыт работы в предметной области

В вышеприведенном случае все характеристика очень высокие и документация содержится по большей части в голове. Но если эту четверку “уйти” и заменить дюжиной студентов под предводительством племянника владельца предприятия, то … На самом деле документация им уже не поможет.

Причина вторая. Некому писать.

Действительно, грамотно описать функциональные требования или глоссарий (я уж не говорю про нефункциональные или, тем более, концепцию), это гораздо сложнее, чем закодировать. В результате, вместо требований, которыми можно пользоваться получается скучнейшие “материалы 35 съезда” изложенные косноязычным тинейдрером, знающего только олбОнский, и то с пятого на десятое. Читать это невозможно. Документация становится Write Only. И, в конце концов,  от написания документации отказываются.

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

Причина третья. Команда не умеет читать.

А вот эта проблема по настоящему серьезная.

Типичный пример того, что никто не умеет читать документацию это фразы вида: «Цель проекта внедрения BTS Jira является автоматизация учета багов.»

Я понимаю, у аналитика писавшего ЭТО был неудачный день. Может зубы у ребенка резались и была бессонная ночь. Может быть гриппом болел и голова не соображала. Но то, что из всей команды никто не сказал “Булшит!”, это показатель неумения читать. Писать документацию в этом случае бесполезно.

Проблему усугубляет странная российская система подбора персонала, когда на место разработчика ищется инженер со скилами кодера. Вот типичнейший пример:

Разработчик Java
Требования:

* Обязательные:
Опыт разработки на Java, знание ООП;
Знание  HTML;
Знание и опыт работы с JSP;
* Желательные:
Опыт работы с каким-либо web-framework’ом (JSF, Struts, GWT, Wicked и т.д.);
Опыт работы с какой-либо AJAX-библиотекой (jQuery, Ext-JS, Prototype);
Опыт работы со Spring framework;
Опыт работы с  JDBC, JPA, Hibernate и подобными средствами (взаимодействие с БД);
Опыт работы с WebShpereAS;
Опыт работы с СУБД Oracle;
Опыт работы с EJB;
Опыт работы с Web-сервисами.

Написано, что ищут разработчика, а в требованиях нет ни навыков анализа, ни умения проектирования GUI ни даже навыков верификации собственного кода. Ни-че-го.

Проводя курсы по написанию документации, я сделал вывод, что на то, чтобы научить инженера с пятилетним опытом написания кода читать документацию нужно 80-160 часов тренингов. Писать спецификации он после этого будет плохо, а вот читать вполне сможет.

Супер фича

Пятница, Декабрь 4th, 2009

Почти что дарю идею.

В обычной социальной сети, в жадносоциальниках, или еще где, начинаем проводить лотерею. Время от времени у каждого аккаунта появляется надпись “Я лох позорный”. Ну или что-то в этом роде. А снять надпись можно послав платную SMS. И еще слоган надо вывесить: “Не будь лохом, следи за аккаунтом!”

То то народ обрадуется! Аж просто рад будет до безумия. А бабок сколько можно получить!

Ну и продолжая идею.

Ведь можно же вместо сигнала дозвона  по сотовому транслировать: “Лох скоро будет на связи”. Снимать такой гудок опять таки за деньги. Скока радости у изобретателей “гудка” и “хамелеона” будет!!!

А еще можно в электричках ходить с плакатом. “Если не дашь 10 руб., то тебя обзовут лохом позорным.”.

Не. В электричках за такой  плакат можно и в торец получить.

Ах, как жаль, что мы, интеллигентные, высококультурные люди не пойдем встречать в темном переулке изобретателей “Гудка” и “Хамелеона”. Как было бы классно подойти, имея десятикратное численное преимущество и сказать огромное, просто таки нечеловеческое спасибо!!!

Но не пойдем.

Пока.

Пока что плодитесь и размножайтесь изобретатели и “Гудка”, и “Хамелеона”. И прочая и прочая и прочая.

ЗЫ. Впрочем есть варианты: http://exler.ru/blog/item/7280/?61