Slider Background

2010

Лидерство, риторика, манипуляции – три в одном

Вы хотите делать неунылые презентации, выигрывать переговоры и так ставить задачу так, чтобы ее с радостью быстро решали? Я тоже хочу. Удается? Иногда – да, иногда нет.

На днях я забрел на замечательную конференцию. Она называлась “Успешный руководитель” и проходила у меня в Самаре. Спешу поделиться своими эмоциями и впечатлениями.


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

Я буду перечислять фамилии тренеров, если вас заинтересуют их мысли – мы можете их найти в интернете. Google знает все. И Яндекс.

Борис Жалило. Мастер класс «Внутренние продажи: как продать задачу?» 

 
Люди делятся на открытых и закрытых. А еще на уверенных и неуверенных. Так образуются четыре типажа людей.

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

И хочет каждый тип своего. Закрытый и неуверенный хочет спокойствия, открытый и неуверенный – комфорта, открытый и уверенный статуса и престижа, закрытый и уверенный – выгоды.

Задачу каждому из них стоит ставить в соответствии с его ожиданиями. А если общаешься сразу со многими – то нужно подпитывать чувства каждого типа.

Борис Жалило очень подробно и с удовольствием рассказывал об этих методах, приводил примеры, давал таблицы сигналов, по которым можно классифицировать человека, запретные слова и слова — бальзам. Было интересно.

Кирилл Гуленков. Технологии отражения и проведения манипулятивных атак

 
Кирилл Гуленков схитрил и поменял свою программу, большую часть своего мастер класса под названием «Ответственные переговоры: техники профилактики и преодоления стресса» он говорил про манипуляции. И очень правильно сделал! Про стресс он тоже рассказал, но отвел этой теме столько, сколько нужно.
Итак, о чем шла речь.

У людей наблюдается три вида поведения: действие, коммуникация и анализ. Первые действуют с помощью давления, побуждая людей поступать так, как они говорят (такие люди-носороги). Коммуникаторы договариваются, они открыты к общению, они убеждают. Люди с аналитическим складом просчитывают все до мелочей, они сдержаны и недоверчивы.

Так получилось, что в противоборстве среди них нет абсолютного чемпиона – человек действия забивает коммуникатора, но сдается перед занудством аналитика, который в свою очередь может пасть жертвой коммуникатора. Это как камень-ножницы-бумага.

Кирилл Гуленков рассказал про теорию, а потом перешел к упражнениям. Он принимал роль заказчика одного из типов, а один из нас пробовал противостоять ему с помощью тех техник, о которых он говорил. Я оказался нерадивым учеником. Мы сидели друг против друга, он представлялся коммуникатором – в итоге я очень быстро сдался и совсем на ровном месте ни за что предоставил ему скидку.

Раньше я читал про эти вещи, но в устах Кирилла они стали как-то понятнее и проще. За что ему спасибо.

Фрэнк Пьюселик. Секреты профессионального коммуникатора

 
Френк дальше всех отошел от плана своего доклада, анонсированного в книжках, которые нам раздали. Вернее даже не отошел от плана, а не дошел до него. За час выступления он показал всего три слайда, включая первый, где он представлялся. Но как он проводил свой мастер-класс! Это был театр одного актера очень высокого уровня. Мимика, жесты, переходы с английского на русский и назад. Содержание не отставало от формы.

Фрэнк говорил про структуру бизнеса в России, про различие конкурентных и контролируемых рынков и бизнеса в них. Говорил про перспективы и про то, что мы сами себя сдерживаем. (Почти дословно, только по-русски: перед забегом мы стреляем себе по ногам и потом начинаем с трудом бежать. Нас спасает то, что так делают все и в таких паралимпийских играх мы оказываемся не хуже остальных). Он говорил про телефоны на совещаниях, регламент ответов на звонки и про лучшие практики коммуникаций. Откуда этот американский тренер знает, как происходит у нас на самом деле? А он действительно знает.

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

Радислав Гандапас. Мощь ораторского искусства

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


Радислав рассказывал про 7 смертных грехов и 7 добродетелей человека, делающего презентацию. Шутки переплетались с серьезными вещами, примеры были подобраны очень удачно. Я бы с удовольствием послушал его еще.
В его примерах я узнавал себя. Например, он говорил, что надо заранее делать план презентации, и вспоминал, что в детстве оставлял полстраницы, чтобы потом вписать план сочинения, когда оно было написано. А я тоже так делал.
А еще Радислав приводил примеры удачных речей. Один пример мне запомнился. Радислав пересказал речь инвестора и миллионера (жалко, не помню имени), выступившем перед выпускниками колледжа. На встрече он рассказал, что после колледжа он не был ни богат, ни успешен. Но у него горели глаза. А у выпускников — сказал тот — глаза не горят. А дальше он сказал, что он инвестор. А что делает инвестор? Он инвестирует деньги и время. А зачем инвестировать в тех, у кого не горят глаза? Правильно, не нужно, поэтому он уходит. И ушел. А чуть не дойдя до конца сцены, где он выступал, он повернулся и сказал: “Да, чуть не забыл. Меня просили закончить на позитивной ноте. Вам — удачи.”. И ушел окончательно. Люди думали, он вернется, обыграет ситуацию, обратит все в шутку. Но он не вернулся. Люди были возмущены, некоторые судились. Но по прошествии времени были проведены исследования, которые показали всплеск успешности у выпускников того года (Только не спрашивайте меня, как это мерили). Их программа не отличалась, и годом раньше и годом позже она была такой же…
Выступление Радислава Гандапаса мне понравилось пожалуй больше всех остальных. Он молодец!
А еще я у него украл перенял идею получать во время презентаций посредством sms вопросы от аудитории.

Два слова о других докладчиках

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

Итог

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

Заповеди разработчика

В свое время на меня была возложена задача курирования молодых разработчиков. Начать было решено с формулировки кратких рекомендаций. Результат перед вами.


1 Коротко и неясно

  1. ЧИТАЙ КОД!
  2. Пиши код, который удобно читать всем остальным
  3. Пиши в комментарии не ЧТО делает код, а ЗАЧЕМ
  4. Предупреждения и подсказки опаснее ошибок компиляции - проект собирается без их устранения

2 Цикл разработки

  1. Постановка задачи руководителем
  2. Выработка решения
  3. Рецензирование решения
  4. Реализация решения
  5. Рецензирование кода
  6. Размещение в системе контроля версий

3 Оформление исходного кода

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

4 Комментарии

  • Первая строка комментария перед объявлениями процедур, классов и т.п. должна давать понять их назначение. Последующие строки описывают те или иные особенности реализации.
  • Комментарии к виртуальным методам должны описывать обстоятельства вызова, а не реализацию - она может быть перекрыта в наследниках.
  • Комментарии в теле процедур и методов не должны описывать, ЧТО делает тот или иной оператор или блок, а должны указывать ЦЕЛЬ, для которой он (оператор) используется.
    1. Цели меняются гораздо реже, чем средства ее реализации
    2. Понять что делает код можно из него самого, понять ЗАЧЕМ по коду бывает нереально.

5 Выбор имен

  • Классы - существительное единственного числа с обязательным префиксом T и опциональными в виде названия фирмы (SMS), если существует библиотечный класс с похожим именем и проекта (ZVK, Plan), если класс не может быть задействован в нескольких наших проектах.
  • Интерфейсы - существительные с префиксом I
  • Процедуры - глагол.
  • Функции - существительное единственного числа при возврате значения и множественного - коллекции. Используется префикс Get для методов чтения свойств и функций, предназначенных для получения внешних данных, префикс Is для логических функций, префикс Create для создающих функций. Функции, которые вызываются для выполнения действия (а не только получения результата) называются как процедуры, так как де-факто ими и являются.
  • Свойства - существительное единственного числа, за исключением свойств-массивов. Для свойств-массивов с целочисленным индексом определяется свойство-спутник с суффиксом Count. Свойство-событие должно иметь префикс On, Before или After. Методы чтения и записи свойств имеют обязательные префиксы Get и Set.
  • Виртуальные методы - глагол с префиксом Do для protected и без префикса для public методов.
  • Название виртуального метода должно отражать цель его вызова, а не реализацию.

6 Операторы

  • Глубина вложения операторов друг в друга должна быть как можно меньшей - большая глубина очень сильно ухудшает читаемость кода.
  • Для уменьшения глубины вложения ветвлений полезно использовать операторы перехода (кроме goto) и raise
  • Для уменьшения глубины вложения конструкций try..finally полезно использовать присвоение очищаемым объектам nil перед try

7 Инкапсуляция

  • Не следует использовать без крайней необходимости имеющиеся глобальные переменные и никогда не стоит добавлять свои
  • Все поля классов - только private
  • Один класс должен выполнять одну задачу, а не совмещать в себе хранение, отображение, редактирование и запись в БД
  • Доступ к полям для потомков и извне класса может осуществляться через свойства
  • Все методы, реализующие интерфейс - обязательно protected и невиртуальные
  • Все, что не используется вне модуля - в implementation
  • Если использование класса тянет за собой большую часть проекта, следует написать для данного использования интерфейс, реализовать его в классе и пользоваться только интерфейсом

8 Обработка ошибок

  • Для обработки ошибок следует использовать только исключения
  • Исключения следует использовать только для обработки ошибок
  • В блоках except следует перевозбуждать (raise) все исключения, которые не обрабатываются явно
  • Категорически не следует "глотать" исключения (except end)
  • Категорически не следует возбуждать исключения базового класса Exception: если нет подходящего библиотечного - надо определить свой
  • Не следует обрабатывать исключения только для записи в лог - это делается автоматически.
  • Любой код должен быть написан с учетом того, что в любом его месте может возникнуть исключение.
  • Всегда возбуждайте исключение при ошибках в конструкторе и никогда не возбуждайте и не ловите исключений в деструкторе - деструктор должен корректно завершаться всегда.
Исчерпывающий источник по обработке ошибок в Delphi

9 Отладка

  • Следует полностью избавляться от всех предупреждений и подсказок компилятора, разумеется, не путем их отключения.
Настройки проектов Delphi с точки зрения поиска ошибок

Как читать лог-файлы

Access Violation в деталях

Почему всегда нужно использовать FreeAndNil вместо Free

10 Утечки ресурсов

  • Возможность утечки ОДНОГО любого ресурса, используемого в пределах подпрограммы, устраняется с помощью try..finally, при этом захват ресурса производится непосредственно перед try, а освобождение - в finally.
  • Возможность утечки ресурсов в создающей (захватывающей) функции, устраняется с помощью try..except, при этом захват ресурса производится перед try, а высвобождение в except с последующим raise.
  • Возможность утечки ресурсов в конструкторе устраняется с помощью сохранения ссылок на захваченные ресурсы в полях объекта и учетом и написанием деструктора, корректно удаляющего частично инициализированный объект. Это связано с порядком создания объекта в Delphi
  1. Выделяется память под объект и заполняется нулями
  2. Выполняется конструктор
  3. Если на предыдущем шаге возбуждено исключение, то вызывается деструктор, освобождается занятая память и перевозбуждается исключение.
  • Если ресурсы представляют собой ссылки на объекты, то в деструкторе достаточно использовать для них FreeAndNil
  • В пределах подпрограммы можно использовать аналогичную технику вместо многократного вложения блоков try..finally, помещая "конструктор" сразу после try и "деструктор" в finally. Так как локальные переменные не инициализируются, то это надо делать вручную, присваивая им nil перед try.
  • Если ресурс не реализован в виде класса и используется неоднократно - надо создать класс, в конструкторе которого осуществляется захват ресурса, а в деструкторе - освобождение. Это сделает использование ресурса более простым и единообразным, а отлов его утечек сведется к отлову утечек памяти.
Поиск утечек ресурсов

Поиск утечек, продолжение

11 Наследование, композиция, реализация, расширение

  • Если необходим функционал одного класса при реализации другого - проще всего использовать композицию, например, добавить ссылку на объект в список полей класса. Ограничения - у нового класса есть доступ только к публичным членам старого, необходимо писать делегирующий код.
  • Если имеющийся класс уже реализует часть возможностей нового, то можно использовать наследование. Ограничение - класс-наследник должен полностью заменять класс-родитель в любых ситуациях - например, для наследника TPersistent необходима корректная реализация Assign.
  • Если необходимо использовать новый класс так же, как имеющийся, но поведение требуется совершенно другое, то надо написать интерфейс, который и реализовать в обоих классах. В результате классы могут наследовать совершенно разным предкам, но со стороны использоваться через интерфейс одинаково. Ограничение - поведение через интерфейс не наследуется.
  • Если необходимо расширить поведение класса-предка (и дать тем самым новые возможности всем потомкам сразу), не вмешиваясь в его код, то можно написать хелпер. Ограничения - никаких виртуальных методов и новых полей, один хелпер на класс в пределах проекта.
    • Не стоит использовать хелперы без крайней необходимости

12 Интерфейсы

  • Об утечках при использовании интерфейсов можно не беспокоиться.
  • Методы, реализующие интерфейс должны быть невиртуальными и не публичными, обычно защищенными.
  • Любой интерфейс содержит как минимум три метода - QueryInterface, AddRef и Release.
  • Эти методы вызываются неявно: первый приведением к ссылке на интерфейс операцией as, второй и третий - при создании новой ссылки на интерфейс и удалении (или выходе из поля видимости).
  • При реализации интерфейсов потомками TObject необходимо реализовывать все три вышеупомянутых метода.
  • Потомки следующих классов имеют реализации QueryInterface, AddRef и Release по умолчанию:
    • TInterfacedObject реализует автоматическое удаление, когда на интерфейсы класса не остается ссылок, поэтому его потомки сразу после создания надо приводить к ссылкам на интерфейс.
    • TComponent игнорирует ссылки на реализуемые интерфейсы и удаляется только вручную, поэтому надо следить чтобы после удаления его потомка не оставалось висячих ссылок на интерфейсы.

13 Визуальные компоненты

  • Фреймы и формы не должны содержать в себе никакой логики, кроме логики отображения и передачи (не исполнения!) команд пользователя.
  • Все возможные варианты команд пользователя должны оформляться в виде Action и помещаться в один ActionList в том же фрейме, в котором эта команда доступна.
  • Автоматически созданные Delphi имена компонентов можно оставлять только для тех из них, на которые нет ссылок в коде методов и нет обработчиков. Осмысленное имя надо задавать до создания первого обработчика для данного компонента, иначе потом придется править имя обработчика вручную.
  • Автоматически созданные имена обработчиков следует менять только при крайней необходимости.
  • Обработчики событий визуальных компонентов не должны занимать более пяти строк. Комментарии к методам-обработчикам должны разъяснять не просто обстоятельства вызова (их как раз видно уже из имени обработчика), но прежде всего его назначение - зачем этот обработчик вообще понадобился.

14 Модули

  • Модуль, используемый более чем в одном проекте - библиотечный модуль.
  • Модуль, не содержащий ничего, кроме констант, интерфейсов, типов (не классов), исключений и вспомогательных процедур - интерфейсный модуль.
  • Модуль, содержащий код обмена данными с пользователем, файловой системой БД. сетью и тп. - модуль ввода-вывода.
  • Все остальные модули - модули логики.
  • Идеальная структура межмодульных зависимостей: интерфейсные модули зависят только от интерфейсных; модули логики - только от интерфейсных и других модулей логики; модули ввода-вывода - только от интерфейсных и других модулей ввода-вывода. Это позволяет эффективно использовать модульные тесты для логики и менять реализацию разных частей проекта независимо друг от друга.

15 Устранение лишних зависимостей

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

День здоровья

20 августа в пятницу мы в СМС-ИТ провели день здоровья. Нам очень повезло, это оказался последний теплый день. Гидрометцентр нас обманул, дождя и тем более грозы не было, а было солнце и теплая вода. Мероприятие прошло на острове Зелененький. На воде нас поджидали байдарки и лодки с ватрушками, лыжами и вейкбордом. На суше мы проводили соревнования по метанию ножей, стрельбе из лука, а также ходили по веревочной переправе. На участке песка между сушей и водой уютно расположились столы, а пиво дружелюбно подмигивало нам из прибоя.

Здесь фотоотчет о мероприятии.
Подробнее

Демоверсия Инфоконт, бесплатное пилотное внедрение и развитие

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

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


Будем ждать результатов.

Кстати, чтобы второй раз не вставать, пара слов об Инфоконт.

Инфоконт – это наша разработка, информационная система производства, такой русский PI System.

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

И еще мы дешевле, хотя как говорят и пишут, конкуренция по цене – это не перспективно. Поэтому мы это не выпячиваем как маркетинговое преимущество, а просто констатируем.

С другой стороны, как писал Гай Кавасаки, это допустимо - позиционироваться как продукт, такой же, как большой конкурент, но более дешевый. Например, Lexus выводили на рынок как автомобиль, такой же хороший как BMW, но на 30% дешевле. Вот и не знаешь, кому верить.

И чтобы третий раз не вставать, пара слов про разработку. Сейчас у нас идет очередной виток разработки, благодаря новым подходам к хранению данных мы выходим на скорость архивации в несколько десятков тысяч параметров в секунду. Плюс у нас появился альтернативный графический редактор. Теперь мы можем создавать как растровые мнемосхемы средствами встроенного редактора Инфоконт, так и векторные в формате WPF средствами Microsoft Expression Blend.

Получается все очень красиво.
Подробнее

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

Месяц назад в моей жизни появился Адизес. В тот день наши разработчики вернулся с конференции Software People 2010. В одном из докладов, сделанных Асхатом Уразбаевым, упоминалась методология Адизеса и был дан жизненный цикл фирмы от возникновения до смерти. Сергей Парфенов, руководитель разработки нашей фирмы, тут же купил книгу “Управление жизненным циклом корпорации”.


Далее я поступил как лиса в сказке (пустите меня на лавочку, хвостик под лавочку…) — в итоге книга оказалась у меня. А потом я уже сам пошел в магазин и купил еще одну, красную (улыбка). Она называлась “Стили менеджмента — эффективные и неэффективные”
.

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

  • На каждом этапе она сталкивается с нормальными и аномальными проблемами, которые Адизес очень точно выделяет. Кстати, за свою жизнь я работал в нескольких фирмах, занимая разные позиции, а также имел возможность наблюдать за другими компаниями. На мой взгляд, Адизес в своих классификациях чертовски прав.
  • При переходе между этапами организация меняется и может завалиться в одну из ловушек, Адизес их достаточно точно описывает.
  • На каждом этапе требуется руководители, обладающие различными сочетаниями производительного (P), администраторского (A), предпринимательского (E) и интегрирующего (I) начал. В сумме получается к сожалению недостижимая для одного человека комбинация PAEI. Отсутствие или наличие этих начал в комбинации двигает организация вперед, отбрасывает назад или загоняет в ловушки.
  • Каждому этапу свойственно различное сочетание полномочий и ответственности, которыми организация наделяет исполнителей. Их сочетание обозначается CAPI и также методично рассматривается Адизесем.
Все этапы кривой жизни фирмы от рождения до смерти, все начала, полномочия и ответственности Адизес описывает очень подробно и вдумчиво. И что интересно, все, о чем он говорит, не противоречит нашим российским реалиям. Скорее всего это происходит потому, что Адизес описывает универсальные вещи, которые выходят за рамки стран и культур.

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

Чем книжки полезны именно мне
Первое, книги дали ключ к распознаванию своего стиля и выделения точки кривой жизни, в которой находится наша фирма. Это знание дает возможность понять, что надо поменять в себе самом, чтобы стать эффективнее. Также это знание дает возможность выделить недостаточно сильные компоненты PAEI и начать поиск людей для их усиления.

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

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

Внутренний блог компании - разработчика ПО

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

Зачем он нужен

Чтобы ответить на этот вопрос нужно представить себе жизнь фирмы-разработчика ПО. Итак, как говорил мой знакомый капитан военного корабля, а теперь процветающий предприниматель, сначала вводная. Есть фирма, занимающаяся разработкой и внедрением собственного ПО. Коллектив в количестве 50 человек сидит в двух офисах. В фирме есть отделы разработки, тестирования, внедрения и техподдержки. В разработке находится около 5 продуктов, параллельно ведутся пара десятков проектов разной сложности.
С определенного момента мы начали понимать, что стали страдать коммуникации.
Люди из разных проектов не знают о работе друг друга. Да и не только в разных. Очень нужный здесь и сейчас человек оказывается в длительной командировке или отпуске. Информация передаются по почте, джаберу или изустно. В итоге либо тратиться много времени на донесение информации, либо начинаются сбои. Это нам надоело.

Как мы его сделали

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

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

Зачем все это надо с научной точки зрения

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

Компромисс. Bugzilla против Word

Когда то давно у нас не было системы отслеживания багов. Потом появился большой Excel файл, а после - Bugzilla, которая и используется последние несколько лет. Когда она появилась, мы нарадоваться не могли. Все казалось упорядоченным, четким, красивым. Шло время.

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

Поэтому я начал мухлевать. У нас есть информационная система Инфоконт, установленная на нескольких десятках объектах. Когда доходят руки, я анализирую ее работу. При этом я открываю Word. Далее просто – скриншот, пояснения, скриншот, пояснения и т.д. Если нужно – я обвожу кружочками проблемные места, рисую стрелочки и т.д. В итоге появляется многостраничный документ, где баги перемежаются с предложениями по улучшению.

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

Почему я так делаю. Во-первых, я не хочу терять темп. Если я сел и начал работать, то prt-sc и ctrl-c мои лучшие друзья, они ускоряют работу в разы. Во-вторых, с распечаткой можно сесть вместе с программистом и пояснить, что ты хочешь. И, в-третьих, потом разработчик быстро внесет исправления. Общая цель - поддержка высокого темпа всей разработки.

В чем минусы. Первый, самый важный – то, что исправления не буду проверены. Второй о сделанных изменениях может никто не узнать.

Когда можно и нельзя использовать этот прием. Наверное, для разработки софта, управляющего ядерным реактором, он не очень годится. Впрочем, и для больших багов, которые имеют шанс появиться в будущем, он не применим. С другой стороны есть нестыковки в интерфейсе, мелкие детали, которые портят чудную бочку меда. Также он применим для компонентов, которые только что вышли из-под пера/клавиатуры и находятся в режиме апробирования.

Неожиданно для себя я недавно получил подтверждение своим мыслям. Теперь я не один. Наши разработчики, вернувшись с конференции Software People 2010, пошли по схожему пути и внедрили следующую практику. Теперь тестировщики не пишут баги по новым фичам и комментарии к вновь открытым багам в Bugzilla, а быстро общаются по аське, телефону или лично. Кончено, крупные и страшные баги вносятся, но их количество принципиально другое. В итоге, скорость исправления увеличилась, а писанина уменьшилась (все же знают анекдот про зайчика, волка и писанину, которая увеличилась).
Подробнее

Scrum-доска своими руками

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

Краткая предыстория.

В апреле-месяце мы с коллегами побывали в столице на конференции SoftwarePeople 2010.
Одним из лейтмотивов конференции были всякие гибкие методологии и конкретно скрам. Если раньше нам как-то удавалось противостоять волне повсеместной скрамизации, то на этот раз мы сдались.

(Вообще о постепенном приходе гибких методологий в жизнь нашей фирмы я собираюсь написать пару отдельных постов, следите за рекламой :)
Итак, что нам надо для одной доски:
  • Белая лаковая пластиковая стеновая панель, размер 37х300 см., 1 шт.
  • П-образный “стартер” для обрамления доски по периметру  -  3 м., 1 шт.
  • F-образный профиль, 3м., 1 шт.
  • Скотч
  • Веревка - 1 метр.
Панель режем на 4 части, длиной по 75 см. Стыкуем друг с другом. С обратной стороны швы проклеиваем скотчем. (По-правильному, конечно, для надежности надо эти панели саморезами крепить к какой-нибудь тонкой деревянной планке, но такой у нас под рукой не оказалось). Периметр обрамляем “стартером”.  А снизу вместо обычного П-образного профиля используем F-образный. Это будет полочка для разных скрепочек и маркеров. Профиль тоже с обратной стороны закрепляем скотчем.
И наконец, дырявим нашу доску в двух местах и крепим веревочку, чтобы повесить ее на стенку.

На такой пластиковой доске можно даже рисовать маркерами для белых досок. А листочки с задачами клеим скотчем.  Пробовали листочки с липким краем – отлетают через неделю.


В итоге – очень даже симпатичная доска размерами 0,75х1,5 м. Стоимость – 300 руб. плюс полчаса на сборку доски всей командой с шутками-прибаутками.
Подробнее

Ищем настоящих тестировщиков

Как у нас проходят собеседования написал Андрей Шопин в посте «Как мы проводим собеседования». Я расскажу о том, что «ищу» в кандидатах на позицию тестировщик. Ну конечно же из множества соискателей, которые пришли к нам на собеседование, хочу отыскать «настоящего тестировщика». Кто же он такой и как его отличить от ненастоящего?

Джоэл в своем блоге (http://www.joelonsoftware.com) пишет, что хорошие тестеры думают методично, им нравится работать с программным обеспечением и решать различные головоломки, даже если для их решения требуется несколько дней. Пожалуй я с ним соглашусь, сама люблю собирать различные паззлы и занимать себя решением кроссвордов на досуге.
От себя добавлю, что настоящий тестировщик должен видеть то, чего не видят другие, смотреть на вещи нестандартно, уметь замечать и учитывать все возможные неточности, несоответствия, противоречия… И он обязательно хочет быть тестировщиком! Не программистом, внедренцем или аналитиком. А именно тестировщиком. В профессии тестера не мало креативного, но есть и суровые тестерские будни, когда одно и тоже действие нужно проделывать по несколько раз в день. И нужно быть готовым к рутинной работе, подписывая трудовой контракт.
За время собеседования невозможно всесторонне оценить навыки кандидата, поэтому мы выдаем «домашнее задание». Это тестовое приложение, в которое наши славные разработчики СПЕЦИАЛЬНО (подчеркиваю двумя чертами) внесли баги. От соискателя требуется написать план тестирования, протестировать приложение, написать отчеты о найденных ошибках. Что мы оцениваем?

  • Содержание плана тестирования
  • Логичность изложения
  • Полноту покрытия функционала тестами
  • Оформление отчетов об ошибках (баг репортов).
Высшим пилотажем считается не просто найти ошибки, которые мы «посадили» в приложении, но и те, о которых мы даже не подозревали. А такой случай у нас уже был. Конечно же, ни у кого не возникло сомнений в природном таланте кандидата и он был принят в штат с распростертыми объятиями. А уж если кандидат найдет ошибки в спецификации и внесет предложения по улучшению функциональности, то нашей радости не будет предела.
Если вы любите работать в команде, у вас есть желание и стремление познавать что-то новое и вы считаете, что сломать систему надо умеючи – присоединяйтесь к нам! Мы ищем тестеров не по должности, а по призванию!
Подробнее

Пишем спецификации. Часть 2. Инструменты. Вики – всё под рукой.

Продолжаю разговор об инструментах, с помощью которых можно сделать такой сложный и непривычный процесс написания спецификаций простым, доступным и даже прикольным (см. Часть 1. Инструменты - начинаем с простого). Я уже давно подумывал о том, чтобы приспособить для этого вики.

Благодарности
На фестивале 404 меня очень заинтересовал доклад Константина Коломейца из Яндекса об использовании различных инструментов для командной работы. Еще более интересной и познавательной оказалась дальнейшая беседа и ответы на вопросы в уголке экспертов на уютном диванчике. Это стало тем толчком, который склонил чашу весов от долгих раздумий к активным действиям.

Вспоминаем требования к инструментам

  • Удобство чтения.
    С этим все просто. Всё, что необходимо, для того, чтобы прочесть спецификацию - это браузер. Навыки работы в браузере наверное есть у всех :)
  • Удобство поиска.
    Найти нужную статью в нашей вики можно двумя способами:
    1. Навигация / ссылки. На боковой панели (sidebar), а также на первой странице вики есть ссылки на все наши проекты, а на главной странице - еще и на описание наших внутренних процессов.
      На головной странице каждого проекта есть ссылки на все (или почти все) статьи по этому проекту. Это такая большая-большая страница, состоящая только из ссылок. Они разбиты по категориям (описание процессов, интерфейс пользователя, межсерверное взаимодействие и т.п.). Там даже есть ссылки на те спецификации, которых еще нет, но которые точно должны быть.
    2. Поиск. Сейчас используется родной поиск MediaWiki. (В интернете есть куча способов, как прикрутить тот или иной продвинутый поисковый движок. Но пока хватает и родного, для того чтобы по одному-двум ключевым словам найти нужную статью.)
  • История изменений. Встроенных средств вполне достаточно.
  • Совместная работа. Встроенных средств разрешения конфликтов - достаточно. При том что редактируя документ не целиком, а конкретный раздел, шансы на создание такого конфликта очень малы. У нас это случается не чаще раза в неделю.
  • Удобство собственно редактирования
    Начинается самое интересное. У меня была задача - сделать так, чтобы нашим коллегам ХОТЕЛОСЬ пользоваться нашим инструментом. Для этого нужно, чтобы простые и повседневные действия не требовали изучения, а делались привычным способом. Дальнейшее изучение инструментария (язык разметки, всякие расширения) должно приносить немедленную и ощутимую пользу - повышать скорость работы или предоставлять новые возможности.
    Ниже я поведаю о том, как я боролся за удобство редактирования.

Набираем инструментарий
1) Движок. MediaWiki
Движков вики много. Не рискну утверждать, что один чем-то лучше другого. Я выбирал подходящий нам.
Во-первых, он бесплатный. Переходя на вики, я не был 100% уверены, что это будет окончательным решением, поэтому рисковать, покупая какую-нибудь коммерческую систему, не хотелось. Тем более что на тот момент для меня (немножко утрирую) все вики были на одно лицо.
Во-вторых, язык реализации. PHP/MySQL. У нас уже были и такие сайты, и такие специалисты, и мы были готовы, если придется, что-нибудь подкручивать-подвинчивать.
В-третьих, большое количество всяких расширений.
Ну и наконец, громкое имя. Я надеялся, что этот движок будет достаточно надежен, раз уж он тянет википедию.

2) Редактор. WikEd + FCKEditor
Конечно, мне хотелось визивига. Любая новая система будет воспринята в штыки, если для работы с ней придется менять свои привычки. В данном случае такой привычкой была работа с текстами. Все умели работать в ворде. А заставлять аналитиков учить всякие языки разметки (пусть и очень простые, но не нужные им для выполнения их основной работы) мне не хотелось. За программистов я был спокоен. После html вики-разметка просто сказка.

FCKEditor - wysiwyg редактор. Похож на Ворд (вы уж простите меня, что я через слово поминаю его, но жизнь такая, что любой ИТ-шник умеет писать в ворде и если повезет, еще в чем-нибудь). Так вот, он похож на ворд. Включая горячие клавиши. Удобно работать с таблицами. Удобно делать ссылки на другие статьи - он сам предлагает на выбор несколько статей по введенному ключевому слову.
Но есть и минусы. Основной - работа с буфером. Вставлять в буфер форматированный текст он соглашается. А вот из буфера - фигушки. Только plain-text. Что неожиданно. Я вырезал абзац, хочу вставить его в начало документа - ан нет. Приходится выделять и тащить мышкой. Я уж не говорю про вставку из ворда (а как нам переносить наши старые спецификации?)
Второй большой минус - не показывается содержимое шаблонов и расширений синтаксиса. То есть видно, что какая-то фигня там внутри есть. Хочешь посмотреть какая - смотри в отдельном окошке. Это неудобно, поскольку у нас есть ряд типовых шаблонов для комментариев в тексте, описаний сценариев и примечаний.
Поэтому одного редактора нам оказалось мало.

WikEd. Полная противоположность. Имеет плюсы там, где у соперника минусы. Но и наоборот.
Минус - он не совсем wysiwyg. Это редактор вики-разметки. Он показывает жирное жирным, а курсивное курсивом, но при этом показывает и разметку. И соответственно, не показывает, что же у нас увидят читатели. Надо жать превью.
Плюс - это, пожалуй, лучший редактор для вики-разметки. Для тех, кто предпочитает её визивигу.
Плюс - возможность вставки из буфера форматированного текста. В частности - из ворда. С последующей конвертацией в вики-разметку.
Минус - он не работает в Internet Explorer. Неудобно, но не критично. Аналитики осваивают firefox. Хуже поклонникам Оперы. Они переходить на firefox не хотят.

Так и живем. Два редактора. Переключаемся из одного в другой, в зависимости от задачи. Первоначальный вариант документа удобно править в FCKEditor. В нем же - работать с таблицами. Окончательную разметку, а также вставлять примечания, удобнее в WikEd.

3) Экспорт. PDFBook + доработка напильником для выгрузки в Word.
Один из вопросов при внедрении вики был - а как нам согласовывать наши спецификации с заказчиком? Вики у нас находится в интрасети, и шансов выставить ее наружу нет никаких. Да и как заказчику писать свои замечания? Тоже учить вики-разметку? Не вариант.
Вариант - экспорт в какой-нибудь общечеловеческий формат. Вы будете смеяться, но это - ворд. PDF можно читать, можно распечатать, но заказчик уже ничего в нем не напишет и не исправит.

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

Мы немного доработали это расширение, и теперь оно же умеет создавать и документы Word.
Ссылки для вызова этого расширения мы добавили в sidebar, и теперь любую страницу можно сохранить в файле doc или pdf.

4) Эскизы экранных форм. Balsamiq Mockup
Это просто чудо. Замечательно простой и прикольный редактор для рисования эскизов UI. Именно эскизов, в отличие, скажем, от Визио. Результирующий рисунок выглядит, как набросок карандашом от руки. И в этом вся прелесть. Рисуя в Визио, эскиз выглядит почти как настоящий интерфейс, и волей-неволей хочется сделать <красиво>. А в Balsamiq Mockup нет такого искушения. Внимание разработчика и заказчика концентрируется на главном - общий дизайн формы, состав и расположение контролов. Не отвлекаясь на такие несущественные моменты, как цвета, шрифты, выравнивание элементов с точностью до пиксела и прочие красоты. Которые, как правило, в рамках проекта определяются style guide.
Еще одно удобство - большой набор строительных блоков - контролов. При этом сложные контролы (например, многоколоночная таблица или дерево) не сложнее простых (кнопок или меток).

Кто пробовал нарисовать в Визио дерево, меня поймет.
Засчёт всего этого скорость рисования интерфейса по сравнению с Визио возрастает в разы.
И наконец, самый главный плюс. Эта штука замечательно интегрируется с Вики. Редактор представляет собой AIR-приложение, которое выполняется прямо на странице вики. И эскиз в своем формате сохраняет также прямо в вики. На сайте разработчика предлагается вариант для xWiki. Но легкая доработка напильником позволила запустить ее и в MediaWiki.
И напоследок должен сказать - это единственное ПЛАТНОЕ расширение (из всех, используемых нами). Но оно того стоит.
Кстати, есть и десктопная версия. (Бесплатная, только каждые 5 минут предлагает купить себя). Её наши аналитики берут с собой, выезжая к заказчикам.

5) UML. PlantUML
С помощью специального синтаксиса прямо в тексте вики-страницы можно <рисовать> UML-диаграммы. А потом по этому текстовому описанию будет построен рисунок. 
    <uml>
       Alice -> Bob: Authentication Request
       Bob --> Alice: Authentication Response
    </uml>

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

6) Расцветка синтаксиса. SyntaxHighlight GeSHi
Во многих спецификациях мы, наряду с диаграммами, сразу набрасываем какой-то код. Хочется, чтобы он выглядел понятно и привычно, как в среде разработки. В этом нам помогает расширение для подсветки синтаксиса. В комплекте идет поддержка кучи языков, мы и не пользуемся всеми ими. Для своего любимого Delphi я немножко подкрутил настройки, чтобы выглядело более похоже на IDE.

Выводы
При правильной настройке вики становится замечательным инструментом для написания (хранения \ поиска \ чтения) спецификаций.
Такой общий блокнот+карандаш, в который можно писать при любом удобном случае. Так мы и стараемся поступать. Знаешь что-нибудь - быстрее запиши в вики, пока не забыл.

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

Ссылки по теме
Подробнее

Пишем спецификации. Инструменты. Часть 1.

Итак, наконец-то мы решили начать писать спецификации. Поскольку сам процесс для нас новый, пускай хотя бы инструменты будут привычными.

Что мы хотим от инструмента? Пожалуй, все требования сводятся к одному слову - удобство. Ведь нужно иметь очень веские причины, чтобы заниматься чем-то, если это делать неудобно. А ведь нам хочется, чтобы наши коллеги получали удовольствие от написания спецификаций. Как, например, от программирования.

Лично у меня требований немного:
  • Удобство поиска. Нужно уметь найти нужную спецификацию по ключевым словам. Или убедиться, что такой спецификации нет.
  • Удобство правки. Чем проще будет процесс написания спецификации, тем с большей охотой наши коллеги будут заниматься этим.
  • Удобство чтения. Заранее известно, что круг читателей наших спецификаций будет шире, чем круг писателей. Это и программисты, которые будут кодировать по этим спецификациям, и тестеры, которые потом проверят то, что накодировали программисты, и даже наши клиенты, которым хочется как можно раньше узнать, что для них накодируют программисты.
Вариант 1. Microsoft Office.

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

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

Со временем мы придумали шаблон оформления типовой спецификации. Нет, это не стандартное содержание из 20 пунктов, которые должны быть в любой спецификации. Боже упаси. Мы описали стили оформления разных смысловых частей:

  • Заголовок спецификации: тема, автор / дата / рецензент
  • Исходная формулировка / требования от заказчика
  • Примечания для тестировщиков
  • Примечания для разработчиков – когда в тексте функциональной спецификации нужно на чем-то заострить их внимание. Если же это целиком техническая спецификация, например описание реализации какой-то хитрой функции на сервере, или всякой там архитектуры, то используем обычный стиль.
  • Сценарий.
Полезная вещь оказалась. Документы стали такими весёлыми, разноцветными, читать приятно. И можно сразу найти нужную часть, даже не вчитываясь в текст, только по внешнему виду.

Чуть позже стало понятно, что нам нужны перекрестные ссылки из одного документа на другой. Благо в Ворд-е есть относительно удобный механизм для этого. Можно делать ссылки и внутри документа, и между документами. Со временем стали появляться документы – порталы, состоящие в основном из ссылок на другие документы.
Иногда (точнее, довольно часто) надо вставить в спецификацию какой-нибудь эскиз интерфейса, или скажем UML-диаграмму. Их мы рисуем в Визио, а потом вставляем в спецификацию. Вопрос – где хранить сами визиевские файлы? Давайте придумаем хитрые правила – для хранения связанных файлов будем создавать папку с именем, как у документа, и в нее класть дополнительные материалы.

Итоги:

  • За полгода работы над одним из наших проектов было порождено порядка тридцати полновесных спецификаций. Их писали аналитик, ведущий разработчик, и некоторые рядовые разработчики.
  • Нам потребовалось:
    • программы из пакета MS Office, по числу пишуших спецификации.
    • общедоступная папка на сервере для хранения документов.
  • Разработаны правила оформления и хранения спецификаций.
Плюсы:
  • Пологая учебная курва ((с) Голубицкий). Для запуска процесса не требуется никаких усилий, кроме волевых. Все необходимые инструменты – офисные программы и сетевой диск – как правило, уже имеются. Сохраняются все навыки работы с документами (если у кого были).
Минусы:
  • Затруднена совместная работа. Если кто-то открыл спецификацию, больше никто в это время ее изменять не может.
  • Нет истории изменений. Сложно понять, что изменилось в спецификации с момента твоего последнего чтения. Даже с помощью продвинутых средств Ворда – рецензирования, можно отслеживать только одну итерацию правки документа. Но и при этом документ становится нечитаемым из за подчеркиваний-перечеркиваний и линий-примечаний.
  • Затруднен поиск. Сложно найти нужную спецификацию, и в ней – нужную часть. Необходимо помнить, хотя бы приблизительно, как называется документ, и потом пытаться найти его среди пятидесяти его товарищей. Да, казалось бы, в windows есть поиск по файлам. Но нужно сделать кучу шаманских действий, чтобы он начал искать по офисным документам. А потом повторить это на всех тридцати компьютерах разработчиков.
Резюме:
Описанный инструментарий вполне достаточен, когда вы только начинаете пробовать свои силы в специфицировании. Его можно использовать в очень небольших проектах с числом разработчиков около пяти. Если же у вас несколько проектов, несколько команд, и главное, вы уже вкусили прелестей спецификаций и вам хочется большего, то вам нужен более продвинутый инструмент. Для себя мы нашли его в Вики. Продолжение следует…
Подробнее

Пишем спецификации. Прелюдия

Пришла мысль написать несколько заметок (две или три) о том, как мы у нас в конторе пишем спецификации.

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

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

Пишем спецификации. Инструменты. Часть 1.
Пишем спецификации. Часть 2. Инструменты. Вики – всё под рукой.

Подробнее

Как мы проводим собеседования

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

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

Пусть у вас есть 8 биллиардных шаров, один из которых чуть тяжелее всех остальных. А остальные одинаковые. У вас также есть весы с двумя чашками, как на рынке, но без гирек. Какое минимальное количество взвешиваний вам нужно для того, чтобы найти самый тяжелый шар.
Если человек дает ответ больше трех, нам становится грустно. Если три - то мы начинаем его подталкивать к правильному ответу. И очень немногие сразу отвечают про два взвешивания. Кстати, мы приняли несколько человек, кто не ответил. Тем не менее, это важное задание.

Однажды мы получили ответ “несколько тысяч”. Оказалось, что товарищ услышал про “восемь миллиардов шаров”. C тех пор я стал говорить “восемь шаров для игры в бильярд”.
Неожиданно для себя я недавно нашел эту задачу в книжке Уильяма Паундстоуна “Как сдвинуть гору Фудзи”. А также множество других задач. Мне самому сложнее всего далась загадка про гномов. Мало того, что я ее не отгадал, так еще три раза прочитал ответ, прежде чем понял. Очаровательна книжка, всем рекомендую.
Продолжаем разговор. После расспросов и задачек мы спрашиваем, что человеку интересно узнать про нас. И отвечаем на все вопросы. Иногда нам говорят, что про нас всё прочитали на сайте. На всякий случай я всегда интересуюсь, что же про нас прочитали. Иногда оказывается, что прочитали про системы промышленной автоматизации, контроллеры и SCADA-системы. Это самый грустный момент собеседования. Это значит, что человек пришел к нам совершенно случайно. К счастью это бывает редко, и большинство переступающих наш порог знает, что мы делаем софт.
После ответов на вопросы мы выдаем задание и неделю времени. Это притом, что сделать его можно намного быстрее. Что мы смотрим, получая результаты? Скажу на примере задания для разработчиков. Нас интересует структура классов, оформление кода, правильные переменные и методы. Если мы видим таймер, то мы очень огорчаемся. А оператор goto повергает нас в ступор. К счастью, мы его никогда не видели.
Дальше - мы получаем задание, встречаем нового программиста, знакомим его с будущими коллегами, сажаем на последнее свободное место. Облегченно вздыхаем и тут неожиданно понимаем, что нам крайне необходим еще один внедренец. Но это уже другая история.
Подробнее

Мы в Вики

В Википедии появилась статья о нашем ПК Заявке/АСУРЭО 

Подробнее

Итоги 2009 года

Сейчас мы подводим итог 2009 года. Год получился интересным, и многое удалось. Мы внедряли перекрестную проверку кода, сняли новый офис и запустили HelpDesk и CRM. Но обо всем по порядку.
  1. На треть увеличился коллектив. Мы приняли 13 человек, у нас уволилось двое, при этом в обоих случаях увольнение произошло, скажем так, по обоюдному желанию. Так что текучка в этом году отсутствует. Хотя и в позапрошлом году мы потеряли только одного человека. Так что в этом плане мы не утратили прошлогодних позиций и даже их улучшили.
  2. Увеличились объемы проектов и продаж. Что важно – увеличился объем техподдержки –денег, постоянно получаемых за поддержку наших продуктов, которые дают стабильный абсолютно прогнозируемый поток денег вне зависимости от других крупных проектов. Что интересно, в общей сумме доходов темп их увеличения превысил темп увеличения коллектива. Так что и в целом и в пересчете на одного сотрудника мы стали работать лучше.
  3. Мы получили несколько новых проектов у одного из наших ключевых заказчиков – ЦДУ. Осталось их сделать. Плюс мы обрели еще одного крупного заказчика – МОЭСК, будем укреплять наше сотрудничество.
  4. Мы сняли новый офис. Раньше мы сидели на двух площадках вместе с коллегами из других фирм группы компаний. А сейчас мы занимаем один из двух этажей в старом офисе и весь новый офис целиком. О, как мы его искали, сколько обошли помещений! Зато сейчас у нас пара офисов на расстоянии пяти минут ходьбы друг от друга, объединенных общей сетью. Пора задумываться об одном большом офисе.
  5. Про улучшения наших процессов разработки хорошо написал Сергей в посте “Тест Джоэла для СМС-ИТ на конец 2009 г.”.
  6. У нас появился выделенный отдел продаж, вернее как он у нас называется, отдел по работе с клиентами. Мы стартовали активные продажи ПК Заявки (это наша разработка) и Softing (это отдельное, не очень типовое для нас направление, о нем расскажу отдельно). В результате кроме увеличения дохода мы получили бОльшую (ударение на первый слог) предсказуемость поставок.
    Вообще, у нас есть два направления работы: разработка новых продуктов и продажа существующих. И если по первому мы всегда активно искали проекты, то по второму клиенты выходили на нас самостоятельно или мы их находили случайно. Теперь появилась методичность. В итоге мы теперь не просто радуемся новым поставкам, но и можем заранее планировать финансы и загрузку людей.
  7. У нас появился собственный HelpDesk. Теперь там ведется вся работа по техподдержке с нашими заказчиками, которые создают там запросы, а мы на них отвечаем. В итоге все участники получают уточнения и ответы по электронной почте и могут посмотреть историю решения вопросов на сайте. Отчеты по работе, списки задач для исполнителей и много другое получаются автоматически. Стало намного удобнее.
  8. Мы сделали два, на первый взгляд несвязанных, шага, объединенных одной общей идеей. Мы начали вкладывать деньги в рекламу и в улучшение внешнего вида наших приложений. Т.е. деньги ушли не на зарплату, аренду или налоги и не на закупку новой техники, а на вещи эфемерные и, как бы так сказать, не являющиеся жизненно необходимыми.
    • Мы стали спонсором первой в России международной конференции «Эффективные технологии управления производством», проводимой организацией MESA. Мы подготовили рекламу, раздали брошюры, приняли участие во всех мероприятиях. В рамках конференции мы рассказали про собственную разработку ПК Инфоконт и про наш опыт внедрения в Волжской ТГК. Это стало одним из наших шагов к продвижению ПК Инфоконт на российском рынке. К тому же, участвуя в мероприятиях организации MESA, мы укрепляем свои позиции как разработчика MES систем.
    • Мы провели рестайлинг ПК Инфоконт, заказав новый дизайн интерфейса у наших друзей из фирмы Турбомилк. В итоге у нас появился очаровательный символ – осьминог (одна голова, много лап, никакая информация не пройдет незамеченной). Он и его щупальца появились в иконках и логотипах приложений. Также все экраны в интерфейсе пользователя обрели гармоничные сбалансированные цвета, красивые иконки и законченный вид. Плюс увеличилась дружественность интерфейса. Про то, как мы проводили рестайлинг, и что в итоге получилось, я напишу отдельно.
    Что объединяет эти два события. Они имеют статусный характер. Мы вышли на новый для нас уровень и начали делать то, о чем год назад не могли и подумать. И это только начало.
И главное, мы не ныли про кризис, а много работали и добились большего темпа роста, чем в последние два года. Теперь главное не останавливаться.
Подробнее

Как мы учимся чему-то новому

У нас есть 3 любимых способа, как научиться чему-то новому, которые неплохо работают.
1) Мы читаем.

Мы читаем умные книги.
Мы очень любим читать умные бумажные книги. (Хотя при случае не брезгуем и электронными).
В СМС-ИТ принято удобная традиция. Если разработчик считает, что ему для работы или развития необходима та или иная книга, он идёт в свой любимый книжный магазин и покупает её. (На самом деле, выбор любимых книжных невелик. Это либо Чакона, либо Озон, ставший недавно доступным и в Самаре, после того как тут открылся его пункт выдачи заказов).
Я люблю пользоваться этой возможностью. Мы с женой часто бываем в Чаконе. Пока она пропадает в отделе учебников и всяких пособий, я иду в свой компьютерный отдел. Я люблю ходить вдоль полок и читать названия всех книг подряд. Во-первых, просто интересно, какие книги в принципе есть, не появилось ли чего-нибудь нового. А во-вторых, я до сих пор не могу понять систему Чаконы, по которой книги стоят на полках. Даже когда точно знаешь, что ищешь, всё равно единственный шанс найти нужную книгу – это просмотреть все полки. Например, в разделе «Интерфейс» книга «About Face» Раскина мирно соседствует с «Программируем интерфейс RS-232».
Чему мы научились благодаря первому способу:
  • Общие правила оформления исходного кода. Сейчас мы составили, и главное, внедрили такие правила для Delphi. Для других языков – PHP и C#, есть некие наброски, но они пока не такие вылизанные, как для Delphi.
  • Теория перекрестного рецензирования кода.
  • Написание спецификаций. Функциональных и технических.
2) Мы учимся у друзей.

Для этого есть другая удобная традиция. Когда мы хотим научиться чему-то, мы учимся этому у наших друзей.
Не все можно прочитать в книгах. Часто, когда читаешь про какую-нибудь методику, можно понять, что делать, иногда даже – как делать. Но сложно найти такие полезные вещи, как «хорошие практики», или «трудности, с которыми придется столкнуться», или «какой инструмент выбрать».
Хорошо, когда есть возможность не собирать все шишки самому, а спросить того, кто уже сделал это до тебя.
Самара не очень большой город. В нём вряд ли наберется больше 10 серьезных программерских контор. Что такое серьезная программерская контора? Это хитросплетение людей, процессов и технологий –в результате выдающих качественные востребованные продукты, имеющие большое количество установок.
Это либо филиалы западных компаний, либо местные товарищи, но работающие опять-же преимущественно на запад. СМС-ИТ среди них выглядит такой белой вороной – и сами местные, и пишем для наших.
Но самое интересное, что все в этой тусовке так или иначе знают друг друга.
Как любит рассказывать Андрей, происходит это так. Мы выбираем знакомого, который знает что-то интересное нам, бухаем выпиваем с ним, и исподволь спрашиваем, а что он думает про интересующий наш вопрос.
Бывает по-разному. Иногда мы приглашаем друзей к нам, показываем им нашу карту, и плавно подводим к заветному шкафчику-бару. Иногда мы сами берем что-нибудь из этого шкафчика и едем в гости к друзьям. Бывает, что встречаемся где-нибудь в Бирхаусе на нейтральной территории. Но неизменным остается состав и сценарий встречи: мы, друзья, что-нибудь в бутылке, расходимся поздно, наутро пытаясь вспомнить, о чем-таки вчера мы говорили J.
Чему мы научились благодаря второму способу:
  • Практика перекрестного рецензирования кода. (тема для отдельной статьи) Нам рассказали многие закулисные детали этого процесса и разные хорошие практики в одной отдельно взятой конторе.
  • Корпоративный блог (да-да, вот этот самый). Прошло чуть ли не пол года, пока эта идея не вылилась во что-то осязаемое.
А еще этим способом мы учились активным продажам. Хотя результат получилось немного неожиданный. Мы решили встретиться с нашим другом, который знал этот вопрос – так у нас появился новый начальник отдела по работе с клиентами.
3) Конференции, выставки и прочие семинары.
Очень похоже на второй способ, но изначально мы идем туда слушать, хотя кончается тем же.
Что мы получили благодаря третьему способу:
  • Balsamic Mockup – просто клёвая программка для прототипирования интерфейсов. Любовь с первого взгляда.
  • Вики – общее хранилище всей информации по проектам и процессам. Рассказали ребята из Яндекса. До этого у нас были какие-то смутные мысли по этому поводу, но только после фестиваля 404 встали все точки над i. Сейчас у нас классная Вика, и наполняется всеми со страшной скоростью и большим удовольствием. (тема для отдельной статьи)
Подробнее