Разработка ПО в регионах

[CLOSED] Книги для всех! Ликвидация товара :-)

2012-11-05T14:55:00.005+03:00

BREAKING NEWS!

Не прошло и двадцати минут, как все книжки нашли нового хозяина! Весь фонд ушел в компанию "Сайтодром".

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

Список книг внутри поста. Большинство книг - технические либо менеджерские, однако в конце списка есть несколько представителей худлита.

"Объектно-ориентированный анализ и проектирование с примерами приложений", Гради Буч, Роберт Максимчук и прочие, третье издание классики - 50 000 р.
"Идеальный руководитель. Почему им нельзя стать и что из этого следует", +CD, Ицхак Адизес - 40 000 р.
"Развитие лидеров", Ицхак Адизес - 40 000 р.
"97 этюдов для арихтекторов программных систем", Нил Форд, Майкл Найгард и многие другие - 20 000 р.
"Креативное программирование 2.0", Роберт Гласс - 20 000 р.
"Факты и заблуждения профессионального программирования", Роберт Гласс - 20 000 р.
"Программирование и конфликты 2.0", Роберт Гласс - 20 000 р.
"Техники креативности. Как найти, оценить и воплотить идею", Йири Шерер - 20 000 р.
"Как решить пять основных проблем команды", Патрик Ленсиони - 20 000 р.
"Как пасти котов. Наставление для программистов, руководящих другими программистами", Дж. Ханк Рейнвотер - 10 000 р.
"Код. Тайный язык информатики", Чарльз Петцольд - 10 000 р.
"Сломай систему! Лекарство от управленческой изжоги", Роберт Таунсенд - 10 000 р.

Книги из следующего списка уходят совершенно бесплатно, у некоторых состояние так себе, некоторые мне не понадобились, а некоторые просто "не зашли":

"Объектно-ориентированный анализ и проектирование систем", Эдвард Йордон, Карл Аргила
"Управление проектами по созданию программного обеспечения", Уокер Ройс
"Руководство Джоэла Спольски по подбору программистов и управлению ими", Джоэл Спольски
"Секреты управления программистами", Александр Орлов
"Успешный IT-аутсорсинг", Элизабет Спарроу
"Дизайн страниц. Before & After", Джон МакВейд
"Apache web-сервер", без CD, Ларс Айбрехт
"Справочное руководство по языку программирования C++ с комментариями", Б. Строустроп, М. Эллис, издание 92 года
"Язык программирования C++", Бьерн Строустроп, издание 91 года
"Программирование на языке Си", Н. Джехани, издание 88 года
"Строительство каркасного дома", Самойлов В.С., Левадный В.С.

Худлит:

"Следы на мне", Евгений Гришковец - 20 000 р.
"Рубашка", Евгений Гришковец - 20 000 р.
"Планка", Евгений Гришковец - 20 000 р.
"Реки", Евгений Гришковец - 20 000 р.
"Асфальт", Евгений Гришковец - 20 000 р.
"А......а", Евгений Гришковец - 20 000 р.
Все шесть книг Гришковца пачкой - 100 000 р.
"Бог ненавидит нас всех", Хэнк Муди - 20 000 р.
"Никола Тесла. Повелитель Вселенной", Марк Сейфер - 20 000 р.

Налетай!

Learning in progress

2012-10-22T17:56:00.000+03:00

Я долго пропадал на просторах интернетов. Дело в том, что в последние несколько месяцев я плотно "подсел" на занимательную штуку под названием MOOC. И время было потрачено не зря, черт возьми! Что есть MOOC? Massive open online course. Это случилось аккурат после окончания самого первого моего курса - по разработке и анализу алгоритмов. Я был надолго потерян для такой бесцельной траты свободного времени, как написание новых заметок в этот блог и даже записался в community Teaching Assistant на одном из курсов :-) Однако, пришло время подвести промежуточные итоги и немного рассказать о пройденных мной курсах.

В хронологическом порядке.

1. Design of Computer Programs, Programming Principles
Курс на Udacity

Вообще, данный курс предназначен скорее для новичков в мире программирования, для тех, кто лишь недавно закончил что-нибудь вроде Computer Science 101. Т.е. уже не является совсем чайником, но в то же время все еще далек от профессиональной разработки ПО. Зачем я на него записался? Ладно, признаюсь: я ~~чайник~~ хотел попробовать Python, пускай и в лабораторных условиях. Это причина номер раз. Была еще одна - курс вел Peter Norvig, крутейший дядька IT индустрии, протыкавший перфокарты, когда многие из нас еще были на стадии спецификаций и абстрактных юзер стори своих родителей.

Минимум теории, максимум кодирования. То, что надо. Свое место нашлось как объяснению базовых принципов построения приложений для новичков, так и рассмотрению языковых конструкций языка Python для таких как я. Лекций, как таковых, не было. Их заменяют последовательности коротких видеороликов, посвященных одному или нескольким аспектам разработки или язка, за каждым из которых следует небольшое задание, как правило с привлечением кодирования. Надо заметить, что такой подход не характерен для курсов на других опробоваванных мной платформах. Честно говоря, до сих пор не могу определиться какой из подходов мне нравится больше: классический с лекциями и практикой или новый с фактическим их переплетением воедино. Кстати, это не значит, что домашних заданий не было. Они были и представляли собой реализацию простых программ, как правило игр типа "камень-ножницы-бумага", "покер" и прочее.

2. Compilers
Курс на Coursera

Представлен Stanford University, преподаватель Alex Aiken. Я не раз слышал мнение от более опытных коллег, что знание внутренней кухни языков программирования из разряда must have. Теперь я готов присоединится к их числу. Серьезно.

Это был, пожалуй, самый сложный и самый длинный (10 недель) из пройденных мной курсов. По началу мне очень хотелось его бросить. Сейчас я очень рад, что смог себя переубедить. Такого количества инсайтов от программирования я, наверное, не испытывал никогда.

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

Были рассмотрены все этапы работы классического компилятора, способы их реализации, а также некоторые сопредельные области: Lexical Analysis, Finite Automata, Parsing (top-down and bottom-up), Semantic Analysis and Type Checking, Code Generation, Runtime Organization, Operational Semantics, Local and Global Optimization, Garbage Collection. А упомянутая выше система вывода доказательств позволила на своей шкуре пройти процесс в роли лексического анализатора, парсера, системы типов, сборщика мусора и всех остальных "участников" процесса.

Если вы программист - обязательно пройдите этот или подобный курс. Или, SICP вам в помощь :-)

3. Software Engineering for SaaS
Был пройден мной на Coursera, однако в данный момент переехал на платформу edX. Это тот самый курс, на который я записался волонтером как community Teaching Assistant для модерации форума и посильной помощи тепершним "студентам".

Данный курс, опять же, рассчитан скорее на начинающих разработчиков. Я записался лишь по одной единственной причине - Ruby и Ruby on Rails. Именно этот язык и фреймворк использовались для выполнения домашних заданий.

Спешу сказать, что кроме практики с Ruby и рельсами, были и другие полезные моменты. Например, я более плотно попробовал практику BDD и познакомился с таким инструментом как Cucumber.

В целом - курс интересный, хотя имеет определенные недостатки, в том числе связанные с новой для него платформой edX. Платформа не без изъянов, но в целом достаточно мощная и сможет потягаться с Coursera, ведь за ней стоят довольно серезьные организации типа MIT и Harvard University. Кроме того, существуют планы по выкладыванию всего проекта в open-source, не знаю как вы, а я уже готов присоединиться к сообществу.

4. Human-Computer Interaction
Курс на Coursera

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

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

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

5. Algorithms, part 1
Курс на Coursera

Отличный курс по алгоритмам и структурам данных. Лично мне он понравился больше, чем курс профессора Тима Раукгх...как-его-там...гардена (no offence, просто фамиля сложная) из Стэнфорда. Естественно, темы лекций и домашних заданий пересекались: от алгоритмов сортировки никуда не деться. Но это, пожалуй, даже нельзя отнести к минусам. Ибо: во-первых, курс вел Robert Sedgewick, известный человек в области Computer Science; во-вторых, домашние задания были сконструированы таким образом, чтобы нужно было непосредственно использовать тот или иной алгоритм с помощью карандаша и бумаги для получения ответов; в-третьих, больше внимания уделено таким любопытнейшим структурам данных как деревья (red-black binary tree, k-d tree etc.)

Единственный минус курса (хотя лично мне он не доставил неудобств) - необходимость выполения домашних заданий с помощью Java, тогда как альтернативный курс позволял использовть любой язык. В остальном - must have для разработчиков ПО.

Совсем скоро стартует вторая часть курса.

6. Functional Programming in Scala (in progress)
Курс на Coursera

Этим курсом я занят в данный момент. Как можно понять из названия, мой главный интерес тут - функциональное программирование и язык Scala как приятное к этому дополнение. Заметьте, курс опять ведет довольно известный в своей области профессионал - Martin Odersky, один из создателей языка Scala.

Структура курса максимально классическая. Лекции и практическое домашнее задание, представляющее собой, конечно же, некоторую порцию программирования на Scala. Иногда эта порция черезчур мала, даже не удается до конца осознать те или иные прелести этого мощного и (субъективно) очень красивого языка. Хотя последнее задание не подкачало, удалось применить много из уже изученного.

Пускай курс еще не закончился, но я уже могу с уверенностью сказать, что очень хочу связать свою программисткую жизнь с языком Scala. Иногда мне кажется, что я не могу объяснить это рационально. А потом: higher-order functions, case classes, pattern matching .... эх! Хороший курс, рекомендую.

Вот и все. Такая получилась хронология событий с апреля по октябрь. Learning in progress...

Design and Analysis of Algorithms I: результаты

2012-04-27T12:30:00.000+03:00

На этой неделе закончилась первая часть онлайн курса Design and Analysis of Algorithms университета Стэнфорда, доступная через платформу Coursera. В среду я нашел время для финального экзамена (потратил два из трех возможных часов, все же попытка только одна), сдал на 29,5 из 30 (ботан!), оставил фидбэк организаторам и теперь готов рассказать как это было :)

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

Итак, весь курс занял 5 недель плюс еще одна, в течении которой можно было сдать финальный экзамен. Ведущий курса - преподаватель Стэнфорда Tim Roughgarden. Учебный процесс достаточно простой:

каждую неделю появляется порция видеолекций общей продолжительностью в среднем два часа (их можно скачать либо смотреть онлайн), некоторые видео - опциональные, т.е. в заданиях не будет по ним вопросов
лекции могут содержать в себе простые вопросы для студентов, для поддержания интерактивности - ответы на них ни на что не влияют, но помогают погрузиться в тему
домашнее задание делится на две части: теоретическую и практическую
теоретическая часть - набор из 5 вопросов по материалам лекций, оценивался в максимум 8 баллов, представлен в виде теста с вариантами ответов (возможно несколько правильных), вопросы были как чисто теоретические так и требующие некоторых вычислений на бумажке, две попытки
практическая часть - оцениваемый в 6 баллов programming assignment, который можно выполнить с помощью любой технологии; скачиваем файл с входными данными и обратно представляем ответ в требуемом формате, пять попыток
по домашнему заданию были дедлайны - две недели со времени публикации задания или к концу курса, но лишь за половину возможных баллов
результирующая оценка курса = 40% теоретических задач + 30% практических + 30% финальный экзамен = максимум 100 баллов; если набрал больше 70 - получаешь сертификат об успешном окончании курса (я набрал 92,5 :-Р)

Далее, о содержании курса и несколько примеров из теоретических домашних заданий - прекрасная возможность проверить не заржавели ли знания у вас в голове :). Оставляйте ответы в комментах, правильные появятся через несколько дней. Практические задания можно посмотреть на гитхабе: https://github.com/ddudnik/algo-class-assignments. В начале каждого файла решения есть полное описание задачи, а в папке resources можно найти все входные данные. Код приведен на Ruby, для первых двух недель есть и на Javа для самопроверки. Я решил не терять замечательной возможности не только изучить материал курса, но и заодно немного изучить Ruby :-)

Итак, чему удалось научиться?

Первая неделя

Само собой - введение. Зачем нам нужно изучать алгоритмы, что собой представляет этот курс и т.п. Далее плавно переходим к общим принципам анализа алгоритмов на примере Merge-Sort, говорим несколько слов об используемой нотации Big O (напомню, что я не математик, поэтому даже это было мне в некоторой степени неизвестно) и изучаем один из основных приемов проектирования алгоритмов - принцип разделяй и властвуй - на примерах подсчета инверсий в массиве (на основе Merge-Sort) и алгоритма Штрассена для умножения матриц.

Примеры вопросов из домашки:

1.1) Assume again two (positive) functions f and g such that f(n)=O(g(n)). Is 2f(n)=O(2g(n)) ? (Multiple answers may be correct.)

Never
Sometimes
Always
Yes if f(n)≤g(n) for all sufficiently large n

1.2) k-way-mergesort. Suppose you are given k sorted arrays, each with n elements, and you want to combine them into a single array of kn elements. Consider the following approach. Using the merge subroutine taught in lecture, you merge the first 2 arrays, then merge the 3rd given array with this merged version of the first two arrays, and so on until you merge in the final (kth) input array. What is the time taken for this strategy, as a function of k and n ? (Optional: can you think of a faster way to do the k-way merge procedure ?)

θ(n*log(k))
θ(n*k^2)
θ(n*k log(n))
θ(n*k*log(k))

Вторая неделя

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

Примеры вопросов:

2.1) This question will give you further practice with the Master Method. Suppose the running time of an algorithm is governed by the recurrence T(n)=9∗T(n/3)+n^2,. What's the overall asymptotic running time (i.e., the value of T(n))?

θ(n^2)
θ(n^2*log(n))
θ(n^log(9))
θ(n*log(n))

2.2) Define the recursion depth of QuickSort to be the maximum number of successive recursive calls before it hits the base case --- equivalently, the number of the last level of the corresponding recursion tree. Note that the recursion depth is a random variable, which depends on which pivots get chosen. What is the recursion depth of QuickSort (both for a best-case choice of pivots, and for a worst-case choice of pivots)?

Best: n, worst: n^2
Best: n, worst: n*log(n)
Best: log(n), worst: n
Best: n^2, worst: n^3

Третья неделя

Выбор (selection) из массива: рандомизированный и детерменированный алгоритмы, их анализ и время исполнения. Графы: их представления (матрица или списки), minimum cut (не знаю как по-русски), алгоритм для определения min cut - Random Contraction algorithm, его анализ и детали реализации.

Примеры вопросов:

3.1) How many min cuts are there in a tree with n nodes (ie. n−1 edges) ?

n
log (n)
n - 2
n - 1

3.2) Let 0.5<α<1 be some constant. Suppose you are looking for the median element in an array using RANDOMIZED SELECT (работает по аналогии с Quicksort, по сути является его частным случаем). What is the probability that after the first iteration the size of the subarray in which the element you are looking for lies is ≤α times the size of the original array?

α
1 - α
2*α - 1
1 - 2*α

Четвертая неделя

Углубляемся в графы и изучаем поиск элементов направленного графа. Алгоритмы поиска: breadth-first search (BFS) и depth-first search (DFS), то бишь поиск в ширину или глубину. Их особенности и возможности применения для практических задач. Алгоритмы топологичской сортировки узлов направленного графа и поиска сильно связанных компонентов (strongly connected components).

Кстати, практическое задание на этой неделе было, пожалуй, наиболее интересным с точки зрения реализации. Нужно было найти сильно связанные компоненты в большом графе. Если сам алогоритм закодировать было легко, то преобразовать программу для работы с большим объемом данных было достаточно интересно. Входной граф содержит более 800 000 узлов и более 5 миллионов(!) связей, задавался файлом размером 70 Мб (по одной строке на связь). После первой (рекурсивной) реализации Ruby просто напросто падал с ошибкой "Stack level too deep!", пришлось менять рекурсию на цикл и хранить стэк самостоятельно.

Примеры вопросов:

4.1) Consider the following problem: given an undirected graph G with n vertices and m edges, and two vertices s and t, does there exist at least one s-t path? If G is given in its adjacency list representation, then the above problem can be solved in O(m+n) time, using BFS or DFS. Suppose instead that G is given in its adjacency *matrix* representation. What running time is required, in the worst case, to solve the computational problem stated above? (Assume that G has no parallel edges.)

θ(n*log(n))
θ(n^2)
θ(n*m)
θ(m^2)

4.2) On adding one extra edge to a directed graph G, the number of strongly connected components...?

... definitely will remain the same
... will decrease by 1
... will never remain the same
... might remain the same

Пятая неделя

Классика: алгоритм Дейкстры для поиска кратчайшего пути между узлами графа. Его анализ, доказательство корректности, детали реализации. Плавный переход к структурам данных, т.к. оптимальная реализация алгоритма Дейкстры использует структуру Heap (не путать с понятием кучи при динамическом распределении памяти). Довольно подробно рассмотрели Hashtables: детали хорошей и плохой(!) реализации, хэш-функции. Типичное применение Heap и Hashtable в программах, типичные операции и время их исполнения.

Примеры вопросов:

5.1) Consider a directed graph with distinct and nonnegative edge lengths and a source vertex s. Fix a destination vertex t, and assume that the graph contains at least one s-t path. Which of the following statements are true?

The shortest s-t path must exclude the maximum-length edge of G.
There is a shortest s-t path with no repeated vertices (i.e., a "simple" or "loopless" such path).
The shortest (i.e., minimum-length) s-t path might have as many as n−1 edges, where n is the number of vertices.
The shortest s-t path must include the minimum-length edge of G.

5.2) Suppose you implement the functionality of a priority queue using a sorted array (e.g., from biggest to smallest). What is the worst-case running time of Insert and Extract-Min, respectively? (Assume that you have a large enough array to accommodate the Insertions that you face.)

Θ(n) and Θ(1)
Θ(1) and Θ(n)
Θ(log(n)) and Θ(n)
Θ(n) and Θ(log(n))

Вот таким получился курс, честно говоря я уже жду второй части. К сожалению, на данный момент неизвестно, будет ли она. К счастью, Coursera, уже объявила, что в августе и нобяре соответственно планируется старт курсов Algorithms, Part One и Algorithms, Part Two - однако от университета Принстона. Так что - записывайтесь!, не упускайте возможности, все же курсы предоставляют одни из лучших университетов США. Я уже записался на курс Compilers, который стартовал на этой неделе.

Вот ссылка на все курсы платформы Coursera: https://www.coursera.org/courses. Среди них не только Computer Science, есть много других интересных курсов (учебные процеесы и длительность у всех отличается). Кстати, есть и конкурирующая организация http://www.udacity.com/courses - курсов тут меньше, но зато они более интерактивные и ведут их достаточно известные в мире IT люди. На этой платформе я записался на курс CS212 Design of Computer Programs - в первую очередь, чтобы познакомится с языком и инфраструктурой Python. Ждите отчета через несколько недель :-)

IT Spring 2012: впечатления и немного статистики

2012-03-22T12:02:00.001+03:00

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

Начало конференции повергло меня в уныние и начало вселять ужас тотальным исчезновением заявленных докладчиков...
...однако очень скоро это исправилось, пришлось даже немного загрузить мозг интересным выступлением Дмитрия Безуглого о системном мышлении
Очень рад встрече со старыми и новыми знакомыми (всем привет!)
Александр Калугин собрал аншлаг и породил жэстачайшые споры в твиттере, а теперь и на dev.by (признаюсь, сам тоже негодовал из-за некоторых тезисов, но разговоры в кулуарах помогли разобраться)
Башня с зефиром - это вам не это (с) +1 Кириллу Голубу за доклад и интерактив с публикой
Отличный вечер в Раковском броваре!
Утро второго дня. Сергей Бережной зарядил всех энергией вместо кофе из-за постоянной нехватки последнего
Захватывающий троллинг, всепоглощающее желание сбегать за попкорном, квинтэссенция тех самых "скандалов и интриг" конференции - доклад Дениса Петелина о том, как же все плохо с образованием белорусских айтишников, попытка ответить на вопрос "Что же все таки с этим делать?" с одной стороны и большие сомнения в истинности заявленной проблемы с другой. Что до меня, то я, скорее, склоняюсь к первым, но, в то же время, с предложенными методами лечения не особо согласен: качественный скачок должен случиться не столько в области образования, сколько в изменении самой компании Епам, которая явно бьется головой о потолок белорусского рынка аутсорсинга.
... прошу прощения за неоднострочность предыдущего пункта :-)
Работа в больших компаниях/корпорациях мне не подходит, доклад об интервью (в целом очень позитивный) помог окончательно это осознать. Главное, чтобы стрела не попала мне в колено :-)
Последнее: незабываемое впечатление от гвоздя программы: четырехмерного куба собственной персоной!

Но, как говорится, это еще не все. ~~Звоните~~ Читайте дальше прямо сейчас, и вы получите небольшую порцию статистики активности в твиттере участников конференции по тэгу #itspring! Зачем? Слишком много благоприятных факторов собралось в одной точке: активность в твиттере действительно была в отличие от прошлогоднего SEF.by, последнее время я увлеченно колупаю Ruby с целью изучения, а также у меня выдался свободный вечер :-)

С помощью Twitter Search API я собрал все твиты с хэштэгом #itspring за последнюю неделю и вот что из этого получилось.

Всего твитов: 690, включая 228 ретвитов
Общее число людей, решивших оставить свой след в этой теме: 2⁷ (сорри, не удержался; для тех, кто плохо дружит с математикой (?!), это равно 128)

Десятка самых активных комментаторов (включая ретвиты):

grodnosoft (69)
suhinini (42)
Avosevich (41)
anotherpm (37)
alexsuslin (36)
AnthonyBY (34)
Frodik_ (31)
pankratov (24)
KatrinLaz (22)
interkrok (21)

Десятка самых активных комментаторов (без ретвитов):

grodnosoft (43)
anotherpm (33)
alexsuslin (31)
AnthonyBY и Frodik_ (28)
pankratov (22)
suhinini (20)
trinya (16)
Avosevich, kirillgolub, interkrok и cornerless (14)
KatrinLaz, Sorvict и darkpashka (11)
yyauheni (9)

(да-да, к подсчетам привлекались главные специалисты из центризберкомов России и Беларуси, так что не удивляйтесь результатам :-)

И на последок, две веселые картинки, чтобы не стало скучно.

Число твитов на используемое приложение

Число твитов на используемую систему

(примечание: для второго графика пришлось выкинуть Mobile Web и TweetDeck, т.к. они ничего не говорят об используемой системе)

Как видим, большинство белорусских айтишников безоговорочно предпочитают iPhone/iPad, с этих устройств было сделано около половины всех твитов. Остальные мобильные системы далеко позади. Не берусь интерпретировать, на каких платформах работали люди, твитившие через веб, поэтому пойдем дальше. Windows Phone занимает почетное третье место, но если быть честным, то это случилось благодаря всего двум пользователям, один из которых сейчас пишет сей абзац :-) (high five @suhinini!). Android чуть отстает (и поделом!), и уж совсем неожиданно попал в этот список одинокий и всеми забытый Symbian. Такая вот картина, которую тяжело назвать сенсационной :-)

До встречи на следующей конференции IT Spring 2013!

В ожидании весны

2012-03-15T11:14:00.002+03:00

Календарная весна с нами уже две недели, однако впереди ждет еще одна - специально для нас, айтишников.

17-18 марта в Минске состоится конференция IT Spring 2012, собравшая под своими знаменами весьма впечатляющую армию докладчиков - настоящих экспертов в своих областях. Аудитория тоже ожидается нешуточная, по сообщениям организаторов билеты закончились еще в начале марта, а большая их часть была выкуплена еще раньше. Один из этих билетов попал и в мои руки, несмотря на долгие раздумья. Не смог я «пройти мимо» заявленной программы конференции, которая, надо признать, выглядит гораздно интереснее, нежели оная с прошлогоднего SEF.by. Итак, кого будем смотреть и слушать?

«Особенности управления продуктовой ИТ-компанией» Юрия Гурского или Асхата Уразбаева о премудростях Lean под названием Value Stream Mapping (заодно, узнаем что это за зверь :-)
«Ключевые архетипы системного мышления и анализ ситуаций в продуктовой и проектной деятельности с их применением» Дмитрия Безуглого (название доклада, конечно, немаленькое и не сразу понятное, но Дмитрия обычно интересно послушать)
Какой-то из докладов Александра Кольцова, Юрия Шиляева или Виктории Придатко. Пока не знаю, какой все-таки выбрать. Если первые два, скорее всего, будут любопытно прослушать, то доклад «HR - лицо компании. Какое лицо, такие и кандидаты» Виктории запросто может привести к маленькому локальному холивару :-)
«Коммуникация с заказчиков в нелетную погоду» Александра Калугина и, скорее всего, следующий за ним «Учимся на ошибках. Подробно о ретроспективе в Agile» Николая Фролова.
«Введение в эмоциональный интеллект для айтишников» Михаила Завилейского
Воскресную часть конференции начнем выступлением Сергея Бережного «Инженерный подход в общении с заказчиком»
... а продолжим однозначно «Большим квадратом работы с людьми» от Александра Орлова и Вячеслава Панкратова
закончим конференцию докладами «Блеск и нищета регламентов» Григория Печенкина и «Модель CAPI - от предпринимательства к профессиональному менеджменту» Ирины Бинецкой (старик Адизес форевер!)

Дальше, конечно же, афтерпати и поезд домой в Гродно с хорошим настроением :-) Конечно же, все происходящее (до поезда) будет траслироваться в twitter, так что посматривайте за хэш-тэгом #itspring

P.S. Обнаружил пропажу Сергея Архипенкова из ряда докладчиков, а так хотелось его послушать. Очень жаль, что не получится.

Сдвиг парадигмы

2012-03-13T15:57:00.000+03:00

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

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

Однако, спасательный круг все-таки есть. Два слова: сдвиг парадигмы. По-моему, звучит просто отлично. Никто и не подумает, что ты просто лентяй, желающий скрыть этот малоприятный факт :-)

Дело в том, что за последние пол-года такой сдвиг действительно произошел. Еще год назад я был до беспамятства увлечен менеджментом в IT. Много читал, слушал умных и интересных людей, стремился развивать свою карьеру именно в этом направлении. Это было интересно и захватывающе. Чего уж говорить - этот блог появился исключительно благодаря увлечению менеджментом. (Нетерпеливый читатель может в этот момент подумать, что, мол, бывает... разочаровался парень в менеджменте и менеджерах... Спешу уверить, ничего подобного не произошло). Даже сменяя работу год назад я думал, что разработчик/программист - это временно. Не пройдет и года, как ты вернешься на «менеджерскую» позицию, все станет на круги своя, Земля возобновит свое движение и проекты снова будут успешно завершаться в рамках сроков и бюджета :-)

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

(Кстати, попробуйте догадаться, что стало для меня самым первым приятным открытием и источником мотивации в работе программистом? Уверяю вас, ответ очень прост. Чтобы сверить его с моим собственным, посмотрите постскриптум в конце статьи.)

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

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

Что же это означает для блога? Тут все логично. Думаю, что тематика изменится в сторону более техническую, чем есть сейчас. Вместе со сменой парадигмы изменились мои предпочтения в плане публикаций. Я начал знакомиться с замечательной экосистемой Ruby, практически окончательно перешел на Linux, записался на онлайн-курс Design and Analysis of Algorithms I от Stanford University, получил новый опыт и улучшил навык в работе с Java и в кодировании как таковом. Не исключено, что кое-что из этого появится на страницах блога. А может быть и все сразу, кто знает?

P.S. Ответ - быстрая обратная связь, результ от затраченных усилий, впечатление, что тебе удалось построить своими руками нечто вполне осязаемое, насколько это слово вообще применимо к программному обеспечению :-)

Code Hard!

2011-11-04T15:27:00.000+03:00

Анализируй это!

2011-07-20T11:54:00.002+03:00

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

Все это очень хорошо, все при деле. Однако, на мой взгляд, есть одно большое НО. Зачастую мы забываем проанализировать конкретные потребности пользователя. Заметьте, не требования, которые он сам нам выставил, а именно его потребности, как человека, который каждый день будет использовать ваше приложение. Какая разница? Она есть. Требование к приложению (особенно функциональное) может звучать так (утрированно): «У нас тут есть вот такие документы и продукты, надо бы их между собой связать, да еще и с возможностью удобного поиска и сортировки». В это же время, потребностью пользователя может быть нечто другое: «Хочу пораньше уйти домой, поэтому мне надо просто выбрать кучу документов с одной стороны, кучу продуктов с другой, нажать красную кнопку и завтра утром получить отчеты в нужной мне и удобной для анализа форме». Или, например, что-нибудь такое: «Во всех документах есть свои нюансы. Было бы очень круто, если бы программа подсвечивала мне только те из них, которые мне нужны в данный момент». Другими словами, придумать можно много чего. Особенно если организация большая и пользователей много.

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

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

Каков же выход из созданной мной только что ситуации? :-)

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

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

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

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

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

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

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

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

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

Несколько скомкано, но во время июльской жары по-другому не получается. Мысли так и норовят разбежаться в стороны :-) Спасибо за внимание и понимание!

Книга месяца: «Исповедь оратора», Скотт Беркун

2011-07-07T12:04:00.003+03:00

Проснувшись сегодня утром, я максимально строго сказал себе «Хватит лентяйничать! Пора бы написать о новой книге месяца! И вообще...». По крайней мере, так это выглядело в моей голове. На деле же получилось что-то вроде «Бла-бла-бла... И вообще...» :-) Однако кружка утреннего чая все же сыграла свою немаловажную роль. Так что, встречайте. Книга второго летнего месяца - «Исповедь оратора» Скотта Беркуна.

На самом деле, не только кружка чая с печеньками послужили катализатором к написанию этого обзора. Главным «ускорителем» стала сама книга. Более того, я ее еще даже не дочитал! Но рассказать о ней хочется уже сейчас.

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

Итак, о чем же она?

Если просто сопоставить название и краткую аннотацию, то становится понятно - эта книга об ораторском искусстве. Много ли таких книг? Достаточно. Заходи в магазин и покупай любую. Но эта книга - не просто одна из многих.

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

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

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

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

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

Всем удачных выступлений!

-

О чем нужно обязательно подумать, развивая сотрудников

2011-06-28T11:12:00.001+03:00

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

О чем нужно обязательно подумать, развивая персонал from Stas Fomin on Vimeo.

Чему хороший ПМ может научиться у хорошего врача

2011-06-10T12:26:00.002+03:00

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

Чему хороший ПМ может научиться у хорошего врача

View another webinar from Ivan Selikhovkin

P.S. А я тем временем пакую вещи - на следующей неделе буду вовсю крутить педали, так сказать, на просторах Беларуси :-)

Книга месяца: «Управляя изменениями», Ицхак Адизес

2011-06-02T11:51:00.003+03:00

Вот оно лето! Собрались на море? Будете целый месяц валяться на пляже, периодически придавая себе импульс только для того, чтобы сходить за очередным коктейлем? Или же создавать вечные ценности у себя на даче? :-) Чтобы вы не делали, книга первого летнего месяца поможет вам поддержать себя в тонусе. Да, она от серьезного автора, но из всех его книг эта, на мой взгляд, самая простая в плане восприятия и самая небольшая в плане объема. Как раз то, что нужно для ленивых летних вечеров.

Эта книга - «Управляя изменениями», ее автор - Ицхак Адизес. Она построена в форме общения пытливого студента со своим преподавателем - «гуру» менеджмента (наверное, автор имеет ввиду себя :-). Студент пытается разобраться что есть управление, каким образом осуществлять его эффективно и что для этого нужно.

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

С чего начинается понимание процесса управления?

Конечно же, с теории. Не будь это старик Адизес :-) Около трети книги (а может и больше) посвящено главной модели теории менеджмента по Адизесу - PAEI. Если вы знакомы с этой моделью (другими словами, читали хоть одну другую его книгу), то первые главы можно смело пролистывать в режиме поверхностного просмотра. Но не пропускайте их совсем! Я же говорил, что книга максимально простая для понимания, поэтому и модель PAEI представлена в ней очень легко, без лишней воды. Кроме того, обсуждение этой модели и ее патологических проявления пропущено через призму принятия и осуществления управленческих решений. Того, что составляет основу проводимого изменения.

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

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

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

Короче говоря, как любит повторять сам автор книги, «дьявол скрывается в деталях», которые в данном случае скрываются внутри книги.

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

Вместо постскриптума: говорят, вчера был день защиты детей :-) Мне тут на днях попалась ссылка с выступлением известного американского комика Джорджа Карлина. Ну такой матерящийся старичок, вы знаете :-) Рассуждает о современном воспитании детей и почему это происходит неправильно (по крайней мене у них там): http://www.youtube.com/watch?v=eXJBRXCKX20

Коротко о философии простоты

2011-05-31T11:00:00.004+03:00

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

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

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

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

Будьте проще, коллеги! (И посмотрите еретическую лекцию о программировании под катом)

Философия простоты, или еретическая лекция о программировании (Никита Прокопов, ADD-2011)

SEF.by 2011: приехали? Отчет о событиях форума и кратко о впечатлениях

2011-05-24T12:51:00.003+03:00

В прошлую пятницу в Минске состоялся очередной Форум по инженерии программного обеспечения, который также известен в народе под именем SEF.by. Сразу скажу, что лично у меня не создалось какого-либо однозначного впечатления о произошедшем событии. Как известно, на каждое действие есть соответствующее противодействие. Вот и в этом случае, положительным моментам обязательно сопутствовали моменты не самые приятные. А истина, как обычно, болтается где-то посередине :)

Некоторые моменты, которые я, надеюсь, очень дипломатично назвал не самыми приятными, вызвали ряд вопросов. Почему видеозаписи докладов доступны только для выступлений компании EPAM Systems? Зачем было называть конференцию «территорией без активных HR мероприятий», особенно при наличии целой огромной секции Insider? Зачем говорить с трибуны, что было прислано так много отличных докладов, что было очень сложно выбирать лучшие из них, и в то же время мучить слушателей рассказами компании IBM? И, наконец, самый главный вопрос жизни на конференциях и всего-всего: когда же появится нормальный Wi-Fi?

А из положительных моментов я бы в первую очередь отметил... Хотя нет, о них позже. Мы ведь в интернетах, а тут, как известно, принято жестко критиковать всех и вся. Кому будет интересно читать, например, про хорошую работу организаторов? :) Поэтому о впечатлениях и вышеозначенных вопросах ниже, а сейчас обратимся непосредственно к программе мероприятия, докладам и докладчикам.

Открытие форума началось с длинного выступления Аркадия Добкина, главы EPAM Systems, который обещал за 20 минут рассказать о всех секретах компании. Ага, щаззз! Вместо этого было похоже, что Аркадий Михайлович решил разрулить еще совсем недавно горевшие огнем холивары на dev.by по поводу заказной и продуктовой разработки. Ударив цифрами по этой животрепещущей проблеме, удалось доказать, что, по большому счету, никакой разницы между ними нет. Так ли это? Посмотрим, думаю холивар из нот оувер, несмотря на все старания :-)

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

Окончательно конференцию расшевелил доклад Александра Юрутя, представителя dev.by, который рассказал о рынке труда белорусской IT-индустрии. Все же слушать (и смотреть) эту статистику оказалось значительно интереснее, нежели читать и разбираться на страницах портала. Некоторые цифры в сравнении с прошлогодними, такие как средний возраст айтишника (стал больше на 1 год), несколько развеселили слушателей и самого докладчика. Думаю, можно смело прогнозировать результаты на год следующий. Еще в очередной раз подтвердилось, что безусловным центром для нашей IT-индустрии является город Минск, 9 из 10 айтишников работают именно там. Я, в свою очередь, попадаю в те 9%, которые отведены всем остальным городам Беларуси.

Первая же сессия докладов (для меня) началась с выступления Александра Калугина о минных полях требований fixed-price проекта. Суть проблемы: требования и спецификации покрывают лишь небольшую часть общего понимания проекта заказчиком и исполнителем. Оставшаяся часть представляет собой настоящее минное поле предположений. Совместимость, безопасность, производительность, работа на отказ и под нагрузкой, технические ограничения - все это часто остается как бы само собой разумеющимся и, в то же самое время, никто может не обратить на эти вопросы внимания до той стадии проекта, когда внесение любых изменений либо слишком дорого, либо совершенно невозможно. Чтобы избежать подобных сценариев развития событий, нужно устанавливать правила игры сразу и заниматься профилактикой: определять границы проекта и приоритеты в разработке еще на pre-sale этапе. Как минимум, нужно определиться чем ваш проект НЕ является. Естественно, все это должно быть пропущено через призму как можно более глубокого понимания бизнеса заказчика.

Для меня в этом докладе был еще и дополнительный интерес. Наконец-то удалось познакомиться с Александром лично, чему я очень рад! Читайте больше о требованиях и разнообразных проблемах маленьких проектов в его блоге, там интересно.

Несколько задержавшись на первом докладе, я не успел к началу следующего на другом этаже, поэтому решил остаться в этом же зале и послушать представителя IBM об управлении процессом создания ПО. Честно говоря, у меня сразу были подозрения, что ничего хорошего от IBM ждать не приходится. Все эти подозрения оправдались уже через 5 минут после начала доклада. По-моему, они так дорожат своим имиджем огромной компании со своей супер-мега-корпоративностью и супер-мега-серьезностью, что напрочь забыли о том, что не все люди такие же как они сами. Да-да, не все могут воспринимать килотонны текста, стрелочек и картинок на одном слайде. Не все способны слушать текста, наполненные до отказа умными терминами. Мы же не на защите докторской диссертации! Кстати, угадайте, в чем их секрет управления проектами по созданию ПО? Как вы думаете? Думаю, что любой, кто хоть раз видел их презентацию, знает правильный ответ - применение продуктов линейки Rational. Вот оно счастье, оказывается.

Короче говоря, до конца дослушать этот доклад мне не удалось и до обеда я грелся на солнышке у входа в гостиницу.

Послеобеденная сессия началась любопытным докладом Кирилла Голуба о том как пройти путь от группы программистов до настоящего бизнеса. Точнее, это был не доклад, а скорее беседа. Лично мне нравится такая подача своих мыслей: минимум слайдов, максимум импровизации от докладчика и интерактивности. Аналогия развития собственного бизнеса и прохождения компьютерной игры очень подкупает своей простотой и наглядностью. Развитие идет поступательно, уровень за уровнем, и каждый раз интерес растет. Что же будет дальше, на следующем уровне? К сожалению, тема развития бизнеса такая обширная, что даже целого дня конференции может не хватить. Конечно же, не хватило 45 минут, отведенных на доклад. Вот бы автор решил поделиться своими невысказанными мыслями! Мне показалось, что этапы развития очень перекликаются с циклом развития корпорации Адизеса, который, кстати, был не раз упомянут на конференции.

Далее, до конца первого дня, проходил Agile круглый стол. Докладов на тему гибкой разработки оказалось так много, что их решили совместить в один блок и дать каждому автору немного эфирного времени. Оно того стоило. Мне больше всего понравился доклад Дамира Тенишева из Exigen Services (Санкт-Петербург) о трудностях оценки задач и планирования. Не поленитесь, поищите его презентацию. Там собрано много так называемых проектных потерь, которые часто забываются при оценке задач и составлении планов.

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

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

Сергей решил потягаться с Ицхаком Адизесом и придумал свой собственный код для IT-менеджера. SMDB (попробуйте переставить буквы) - что за этим стоит? (S)ervice - сервис для команды, защита от рутины и бюрократии, помощь в улучшении, (M)ethodology - знание процессов, методологии и практики, их адаптация и улучшения, (B)usiness - предметная область, знание продукта и заказчика, (D)ecisions - эффективное принятие решений, ответственность. Что же, код, пожалуй, полезный. Главное, как говорится, без фанатизма :-)

На самом деле, во многом выбрал этот доклад, т.к. хотелось наконец-то с Сергеем познакомится. А то все twitter да twitter - несерьезно как-то :-)

Дальше был интереснейший рассказ Григория Баркана из Лаборатории Касперского о разработке тиражируемого продукта и соответствующей бизнес-модели. У меня в блокноте ушло больше всего листов именно на этот доклад. Есть конечно недостаток в том, что с колокольни Лаборатории Касперского все выглядит очень просто и идеально. Для начинающих продуктовых компаний вряд ли все может сложится так легко и просто, поэтому не все принципы можно смело применять (например, вряд ли получится на первых порах не разрешать продажникам обещать клиентам разнообразные еще не сделанные фичи и бенефиты продукта). Далее раскрывать этот доклад здесь не буду, автор вроде как собирается сообразить слайд-каст, поэтому подождем. Лучше узнать обо всем из первых рук, чем читать чьи-то несвязные пересказы, правда? :) (помониторьте твиттер по тэгу #sefby)

К своему завершению конференция продвигалась совсем уж по пятничному - т.е. сразу после обеда. Ребята из Itransition решили организовать свободный от заданной темы круглый стол. Да не просто круглый стол, а целый IT-паб с пивом! Должен сказать, что обсуждение пошло буквально после первого бокала. Кстати, людей было немного, видимо не все внимательно слушали представителя Itransitoin на открытии конференции и не услышали ключевых слов о том, что будет пиво :-)

На сессии закрытия пришлось довольно долго ждать участников секции EPAM Insider, хотя, учитывая, что для некоторых фуршет в каком-то смысле уже начался, было нескучно. Кстати, мало того, что их пришлось долго ждать, так они еще по приходу всем на зависть разыграли среди своих участников Kindle и iPad! Эх...

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

Что же, время подводить итоги и делиться впечатлениями.

Плюсы:

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

Минусы:

Нет видеозаписей!
Слишком много EPAM вокруг (по-моему портрет компании в обеденном перерыве в первый день вообще был лишним). Я, конечно, понимаю, что они главный спонсор (за это спасибо) и крупнейшая IT-компания в Беларуси, но иногда это напрягало.
Доклады, явно впихнутые по каким-то политическим причинам. Имею ввиду доклады от IBM. Если бы они были интересными, уверен, что никто бы и слова против не сказал, а так...
Судя по низкой активности в твиттере (не сравнить с потоками сообщений во время SoftwarePeople), конференции надо двигаться в сторону большей популяризации. Или, с другой стороны, белорусским айтишникам становиться более активными? Короче говоря, этот факт создал некое удручающие впечатление.

Таким выглядел Форум по инженерии ПО в этом году глазами айтишника из Гродно. Желаю организаторам добавить плюсов и убавить минусов и, конечно же, ждем продолжения через год!

Software Engineering Forum 2011: поехали?

2011-05-18T17:43:00.002+03:00

Завтра стартует Software Engeneering Forum 2011, а я стартую в дорогу на оный уже сегодня поздно вечером из Гродно. Давненько не бывал на таких массовых мероприятиях для айтишников лично, все как-то виртуально да виртуально. Пора бы уже и с народом познакомиться да порассуждать за кружкой гиннеса о судьбах отечественной IT-индустрии, правда?

Но прежде, чем рассуждать самому, стоит и послушать других :) Лично для себя я составил вот такую сетку докладов:

Минное поле требований fixed-price проекта (Александр Калугин, Mercury Development Russia, Россия)
No more Devs VS Ops - building integrated Development & Operations approach (Eli Feldman, EPAM Systems, США)
От коллектива программистов к полноценному бизнесу: проблемы развития IT-компаний (Кирилл Голуб, Aheadworks/ Пятый терминал, Могилев, Беларусь)
Agile Круглый стол
Think mobile, think innovative (Иван Киркоров, Евгений Гальпер, EPAM Systems)
Evolution of e-commerce, latest trends and implementation platforms (Валерий Маковик, EPAM Systems)
Почему команда не «принимает» руководителя проекта и что с этим делать? (Сергей Бережной, anotherpm.com, Украина)
Разработка тиражируемого продукта: преимущества бизнес-модели (Георгий Баркан, Kaspersky Lab, Москва, Россия)
То ли непонятный круглый стол от Itransition, то ли... еще не знаю.

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

Обещаю более-менее прямую трансляцию с места событий в твиттере, следите за публикациями http://twitter.com/grodnosoft или по тэгу #sefby.

Еще интересно как будет выглядеть футбольный матч с EPAM и совсем непонятно зачем участникам конференции рисовать коллективный портрет EPAM (хотя в тоже время интересно на что он будет в итоге похож: получится ли страшное и большое чудище или нет? :-P). Будем посмотреть, как говорится.

До встречи на форуме!

Теория и практика адаптивного управления проектами

2011-05-14T12:52:00.001+03:00

Предлагаю посмотреть видео выступления Сергея Архипенкова на конференции Codefest 2011 в Новосибирске. Идеи далеко не революционные, но зато очень удачно, на мой взгляд, поданы в виде нескольких основных принципов управления сдобренных ситуациями из практики. Кроме того, автору удалась удачная параллель между развитием науки управления проектами по разработке ПО и развитием механизмов управления баллистическими ракетами :)

CodeFest2011.Arkhipenkov-adaptive_project_management from codefest on Vimeo.

Описание с сайта конференции:

Известно, что производительность программистов может отличаться в десятки раз. Задача руководителя — сделать воспроизводимой высокую эффективность интеллектуальной деятельности. Путь к решению этой задачи — применение методов адаптивного управления, направленных на изучение и изменение свойств и структуры объекта управления: людей и их взаимодействия. Будут представлены и проиллюстрированы практическими примерами принципы адаптивного управления проектом, используя которые, руководитель может обеспечить наивысшую производительность команды. Цель — показать, что хорошо управляемый проект может быть успешно выполнен обычной командой разработчиков.

Обновления блога: Заметки айтишника версии 1.2

2011-05-10T13:30:00.005+03:00

Прикинул, что за последние пару месяцев случилось несколько важных изменений. Поэтому решил, так сказать, подвести очередную черту. Разработка ПО в регионах - заметки айтишника версии 1.2. А вот и changelog:

Самое главное событие: автор сих заметок сменил работу :) Теперь я тружусь в составе команды, разрабатывающей open-source продукт JFire ERP (немецкая компания NightLabs GmbH)
По следам недавних литературных обзоров появилась страница «Что почитать?», которая будет обновляться по мере прочтения новых книг
Вместо довольно убогих (ждем обновлений от Blogger!) родных комментов была подключена система комментирования от Disqus, поддерживающая много способов авторизации, в том числе через аккаунты Twitter и Facebook. Анонимные комментарии по прежнему возможны. Так что, если вы не бот, то смело комментируйте.
Появились кнопки Like и Tweet в постах - жмите, не стесняйтесь ;-)
Прицеплен свой favicon на тему мирного сосуществования людей и багов вместо стандартной буквы Б от Blogger'а
Решился и добавил лицензирование от Creative Commons, которое можно лицезреть в самом низу. Если вкратце, то все материалы можно использовать как угодно, лишь бы был указан автор.

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

Конечно же, любые идеи со стороны жесточайше приветствуются :-)

Книга месяца: «Философия Java», Брюс Эккель

2011-05-05T11:13:00.001+03:00

Меня время от времени спрашивают какие хорошие и стоящие книги можно почитать Java-программисту. Несмотря на то, что таковых книг ни одна и ни две, я всегда советую книгу Брюса Эккеля «Философия Java» (или «Thinking in Java» в оригинале). Уверен, что все Java-разработчики со стажем должны об этой книге знать и уже давным-давно прочитать. Если же по каким-либо причинам этого еще не произошло, то время исправить сие упущение.

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

Что же касается новичков в мире Java (такие ведь еще остались, правда?), то по моему мнению более удачной книги для начала не придумаешь. Как показывает практика, новички зачастую знают об объектно-ориентированном проектировании/программировании немного - лишь голую, ничем не подкрепленную, теорию. Каким волшебным образом эта теория используется на практике понимают далеко не все. Это нормально, мы все учимся. Автор книги, судя по всему, прекрасно осведомлен о таком положении вещей и поэтому начинает с азов ООП, постепенно подводя неискушенного читателя непосредственно к Java.

Кроме общего обзора языка и его основных понятий и управляющих конструкций, которые неизменно присутствуют в любой технической книге, Брюс уделяет внимание более интересным и полезным вещам.

Например о способах работы сборщика мусора я узнал именно из этой книги. Почему так? Да потому, что среднестатистический разработчик не имеет дело со сборкой мусора и борьбой за утечки памяти каждый день. Уверен, многие программисты «поднимают» эту тему только в случае крайней необходимости, когда утечка уже случилась и надо что-то делать. А в остальных случаях, казалось бы, можно об этом и не вспоминать, Java все сделает за тебя. Но мы-то знаем, что это не так. Как бы нам не хотелось, чтобы управление памятью происходило без участия программиста, в реальности мы видим другую картину. И в этой картине именно на плечи разработчика ложится эффективное управления памятью.

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

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

Лично для меня такими темами были:

эффективное использование внутренних классов, приемы проектирования
работа с системой ввода-вывода, стандартные потоки и новый ввод-вывод (nio) - то, что постоянно забывается и каждый раз заново ищется по интернетам :)
параллельные вычисления

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

Книги об управлении проектами

2011-04-28T11:20:00.004+03:00

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

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

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

Начнем, безусловно, с классики жанра.

«Deadline. Роман об управлении проектами»
Автор: Том ДеМарко

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

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

«Искусство управления IT-проектами»
Автор: Скотт Беркун

Читал эту книгу когда-то в оригинале («The Art of Project Management» или «Making Things Happen», читается легче, чем перевод), сейчас перечитываю в русском переводе. Лично для меня она является настоящим справочником на все времена. Тут охватывается, наверное, каждый аспект управления IT-проектом. Причем написана она человеком, который съел вагон собак на руководстве проектами по созданию ПО. Это можно проследить в каждой главе: минимум теории, максимум практических замечаний сгруппированных в удобные check-списки.

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

Именно в этих отдельных «шагах» и помогает разобраться данная книга. Дьявол (или бог, как кому нравится) всегда в деталях, правда?

«Мифический человеко-месяц или как создаются программные системы»
Автор: Фредерик Брукс

Слыхали про закон Брукса? Конечно же! А про его легендарную книгу? Само собой! Так для чего же я тут тогда распинаюсь, спросите вы? С удовольствием отвечаю - чтобы внести свою лепту в процесс стремления к нулю количества айтишников, не знакомых с данным бестселлером.

Пожалуй, с ходу не найти другой популярной книги об управлении проектами в IT, которая была бы настолько проверена временем и подтверждена многочисленным опытом уже не одного поколения специалистов. Впервые она была издана более 35(!) лет назад. И с тех самых времен в основных принципах создания ПО мало что изменилось. Безусловно, изменения как таковые были. Но среди них не было ни одного, по-настоящему революционного, способного в корне изменить отношение к управлению проектами.

Если вы думаете, что столкнулись с малоизученной или уникальной проблемой в процессе создания программного обеспечения, пролистайте эту книгу. Но только сделайте это вдумчиво. За такое время изменилась терминология и форма, но содержание, скорее всего, осталось все тем же. И, быть может, окажется, что вы не одиноки в IT-вселенной и проблема давно известна. Остается подобрать правильный ключ к ее решению и я думаю, что Брукс все еще способен помочь в этом.

«Путь камикадзе»
Автор: Эдвард Йордон

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

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

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

«Управление сложными Интернет-проектами»
Автор: Эдвард Йордон

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

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

Другими словами, в этой книге автор говорит про нашу с вами современную реальность. Если первая работа больше отсылала нас в прошлое (конец 20-го века), то эта находится намного ближе к настоящему (начало 21-го века). И это несмотря на то, что обе они писались приблизительно в одно и то же время на стыке девяностых и двухтысячных. Видимо, не будь краха «доткомов» в начале века, сейчас эту книгу также можно было бы зачислить в ранг славного прошлого IT-индустрии.

«Управление проектами по созданию программного обеспечения»
Автор: Уокер Ройс

Книга, конечно, непростая для чтения. Лично мне было достаточно сложно. Быть может в оригинале она выглядит попроще, но я с ним не знаком. Вообще Уокер Ройс и его отец Уинстон, сделали достаточно много в плане методологий управления проектами по созданию программного обеспечения. Я не так давно в одном из постов публиковал ролик за авторством Максима Дорофеева о том, откуда же взялся водопадный цикл и кто за этим стоит, посмотрите, если еще не видели - не пожалеете.

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

Еще добавлю, что эту книгу ни в коем случае не стоит читать новичкам в управлении проектами. Запросто может отбить охоту этим заниматься :-)

«Управление высокотехнологичными программами и проектами»
Автор: Рассел Арчибальд

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

Поэтому тут закончу вопросом. Друзья, коллеги, кто-нибудь уже читал? Если да, то буду премного благодарен за отзывы в комментариях.

Вот и все. Эпопея в трех актах временно закончилась. Вообще у меня в планах объединить все три публикации на отдельной странице и периодических их пополнять, все же книжная полка все разрастается и разрастается. Так что, следите за обновлениями :-)

Java навсегда!

2011-04-22T11:06:00.001+03:00

Видео, раскрывающее еще одну сторону вечного холивара в стиле «Кто круче? Терминатор или Рэмбо?». Как видим, несогласие по такому непростому и очень важному вопросу может запросто привести к самым драматическим последствиям. Знаю, что видео уже давно боян, но вдруг еще кто-то не видел. Да и нравится оно мне :)

P.S. Думаю, что Терминатор все же круче, чем Рэмбо :)

Если бы программы создавали так же, как автомобили…

2011-04-15T10:53:00.003+03:00

Пока организаторы конференции SoftwarePeople 2011 не выложили в открытый доступ видеозаписи докладов, предлагаю вам посмотреть и послушать презентацию Максима Дорофеева, который уже успел это сделать.

А в своем рассказе он успел сделать еще больше: рассказать об автомобилестроении, об идеях, которые удачно мигрировали в IT индустрию, об успехе Toyota и, конечно же, о бережливом производстве. Если бы это было все, то можно было бы смело сказать: «Ок, это все можно найти и прочитать самому. Спасибо за удобную компиляцию всех этих интересных фактов и рассказов, но…» Но дело в том, что это далеко не все. Максим очень просто и доходчиво рассказал об адаптации и применении best practicies бережливого производства в реальной команде разработки вполне реальной компании «Лаборатория Касперского» :) Никаких сферических программистов и команд в вакууме – все успешно применяется на практике. Так что, рекомендую к просмотру!

softwarepeople11

View more webinars from Maxim Dorofeev

SoftwarePeople 2011: впечатления

2011-04-11T11:59:00.003+03:00

Кратко о впечатлениях моего виртуального присутствия на конференции SoftwarePeople 2011.

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

Из заявленных в этот день тем мне показались интересными только два из трех просмотренных. «Agile через непрерывное планирование» Ютты Экстейн (независимый эксперт из Германии) откровенно разочаровал. Доклад на тему agile ее соотечественника Питера Хрущки на прошлогодней конференции был на порядок интереснее, видимо уровень Atlantic Systems Guild дает о себе знать. А в этом году участникам конференции пришлось в очередной раз слушать некое подобие доклада на общее понимания гибких методологий, зачем они нужны и в чем их смысл. Не самое интересное занятие в наше время, когда только ленивый ничего не знает и не говорит о гибких методологиях. В один момент мне показалось, что даже переводчик немного заскучал :-) Отзывы людей в твиттере во время доклада, кстати говоря, также не блистали особым оптимизмом по поводу услышанного.

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

Рассказ Юрия Шиляева об образовательных программах в EPAM Systems впечатлил. Честно говоря, не ожидал, что в наши постсоветских монстрах аутсорсинга будут созданы такие условия для профессионального развития. Образовательные программы охватывают кучу людей и различных тем тренингов от программирования до менеджмента. Похоже, что им впору открывать свой собственный университет :-) Если вы топ-менеджер большой компании, занимающейся разработкой ПО, то обязательно посмотрите видеозапись - узнаете с какими трудностями можно столкнутся, как из избежать и что может дать наличие такой образовательной программы вашей компании в перспективе. Если вы не топ-менеджер (а таких большинство), посмотрите хотя бы из любопытства. Учитывая в целом негативную оценку компании EPAM со стороны белорусского IT-сообщества, смею предположить, что ваше мнение может измениться к лучшему. И да, я там никогда не работал и не работаю, так что не сочтите за рекламу :-)

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

Командная аллергия: как ее избежать когда в команду приходит новый человек? (Слава Панкратов, независимый консультант)
Современные командные принципы (Влад Балин, Финам)
Если бы программы создавали также как автомобили... (Максим Дорофеев, Лаборатория Касперского)
Эффективная работа с командой заказчика (Сергей Бережной, Global Logic)
Создание приложения под iOS на примере «Sсhety (Счеты) для iPad»
Почему иногда правильное управление проектами ведет к неправильному управлению продуктами? (Дмитрий Безуглый, Системный подход)

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

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

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

Доклад об управлении продуктами от Дмитрия Безуглого к сожалению был в конце дня. У меня, да и у участников конференции наверное тоже, уже притупилось восприятия. А доклад был очень даже любопытный. Вообще, на тему product management редко удается послушать или почитать что-либо действительно стоящее. Поэтому обязательно пересмотрю этот доклад еще раз в здравом уме и трезвой памяти :-)

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

SoftwarePeople 2011: начало

2011-04-07T09:52:00.001+03:00

Сегодня начала работу основная часть замечательной конференции SofwarePeople 2011. В этом году в цифрах она выглядит вот так: 40 спикеров из 6 стран в 4 потока. Участвуют практически все эксперты IT индустрии с просторов СНГ. Дополнительный интерес состоит в том, что по условиям конференции все доклады должны быть прочитаны в России впервые. А так как самые интересные IT-события такого масштаба в основном там и проходят, то практически весь материал будет любопытным и не будет напоминать старую, давно надоевшую пластинку.

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

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

Agile через непрерывное планирование (Ютта Экстейн, независимый эксперт)
Hadoop Streaming: простой путь к масштабированию приложений обработки данных (Алексей Воропаев, Mail.ru)
Программа обучения на 50.000 человеко-часов или как отстроить образовательную программу в IT-компании (Юрий Шиляев, EPAM Systems)
Современные командные принципы (Влад Балин, Финам) - тут наверняка все будет четко и по делу
Если бы программы создавали также как автомобили... (Максим Дорофеев, Лаборатория Касперского) - можно смотреть и слушать этого докладчика на любую тему, некоторые его презентации проскакивали в моих публикациях

Ждем-с. Думаю, будет интересно. И завидую всем, кто принимает непосредственное участие :-)

Книга месяца: «iКона. Стив Джобс», Джеффри Янг и Вильям Саймон

2011-04-04T11:35:00.004+03:00

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

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

Мне кажется, что «iКона» за авторством Джеффри Янга и Вильяма Саймона будет интересна любой из вышеперечисленных категорий. Одни смогут жадно насладиться восхождением Стива к успеху, другие - позлорадствовать над его неудачами и сокрушительным падением. Третьи, к которым отношу себя и я в том числе, смогут узнать много нового и любопытного, местами неожиданного, и проследить за развитием не только IT индустрии, но и других, на которые так или иначе Стив Джобс оказал свое влияние. Кстати, в Apple эту книгу невзлюбили, что только добавляет ей скандальной популярности.

Все начинается с пиратов силиконовой долины. Если вы не смотрели этот фильм - рекомендую. Если не хотите этого делать - можете просто прочитать первую часть книги. О дерзких молодых ребятах, позволяющих себе вольности в отношении к таким монстрам бизнеса, как IBM. О классике создания великих компаний - постройке первого компьютера в гараже. Романтика да и только!

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

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

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

«История игрушек», «Корпорация монстров», «В поисках Немо» - все это замечательные работы компании Pixar. Казалось бы, причем здесь Стив? Сам он ничего не сделал - всю работу выполнили потрясающе талантливые люди во главе с Джоном Лассетером (который до сих пор нас радует, но уже в составе Walt Disney). Работа Джобса - каким-то образом поверить в это направление кинематографа и обеспечить довольно выгодную сделку с Walt Disney (до непосредственной продажи).

Вторым фактом биографии, не связанным с IT и интересным мне, было развитие медийного бизнеса. Да, тут опять же не было придумано ничего нового. Технически все условия для распространения музыки через сеть уже существовали. Но Стив оказался именно тем необходимым катализатором, без которого все это никак не хотело работать. Заслуга Apple велика, однако в политике компании красной нитью проявляется сложный и противоречивый характер Стива: все что не распространяется через iTunes, должно умереть. Тут я намеренно сгущаю краски - лично мне очень не нравится текущая политика этой компании и даже иногда заставляет временно переметнуться в лагерь ненавистников :-)

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

Книги для менеджеров

2011-03-24T16:15:00.004+02:00

Продолжу выполнять обещания. Сделав подборку книг для программистов обратимся к книгам для менеджеров.

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

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

Но вернемся к книгам. Что почитать вырвавшему час-два свободного времени менеджеру?

«Человеческий фактор. Успешные проекты и команды»
Авторы: Том ДеМарко и Тимоти Листер

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

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

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

«Идеальный руководитель. Почему им нельзя стать и что из этого следует»
Автор: Ицхак Адизес

Это одна из многих книг Адизеса, посвященных менеджменту в организациях и применению придуманного им фреймворка для описания менеджерских ролей PAEI. Если в других работах он много пишет об организационном менеджменте как таковом (например, классическая книга «Управление жизненным циклом корпорации»), то конкретно это издание больше сконцентрировано на персоне руководителя, менеджера. Адизес разбивает в пух и прах миф об идеальном руководителе. По его мнению для того, чтобы одновременно осуществлять все необходимые организации функции (P-производство, A-администрирование, E-предпринимательство, I-интеграция), руководителю необходимо обладать многочисленными, порой взаимоисключающими, навыками. Менеджмент - это слишком сложный процесс, чтобы с ним мог справиться один единственный человек. Идеального менеджера не существует, поэтому не нужно тратить усилия на его поиски и/или развитие.

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

«Управляя изменениями»
Автор: Ицхак Адизес

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

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

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

«Becoming a Master Manager: A Competency Framework»
Авторы: Robert E. Quinn, Michael P. Thompson, Sue R. Faerman, Michael R. McGrath

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

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

«Балдеющие от адреналина и зомбированные шаблонами»
Авторы: Том ДеМарко, Тимоти Листер и другие

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

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

«Как пасти котов»
Автор: Дж. Ханк Рейнвотер

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

Данная книга как раз о таком случае. Она компактно рассказывает о многих вещах, важных для любого руководителя и при этом очень хорошо учитывает айтишную специфику. Автор расскажет как привыкнуть к роли руководителя и понять своих подчиненных (удачно сравнивая программистов с разными породами котов). Как развить свой успех и стать настоящим лидером. Как успешно руководить командой и добиваться нужных результатов. Во многом рекомендации автора строятся на других известных работах о менеджменте в IT. Например, многие идеи были высказаны в «Человеческом факторе», описанном выше. Но это не минус данной книги - вряд ли у вас есть время прочесть много книг :-) Вместо этого можно прочитать одну и наметить для себя пути для дальнейшего развития как успешного лидера и руководителя.

«Смерть от совещаний»
Автор: Патрик Ленсиони

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

Ее чтение не займет у вас много времени: по объему она совсем небольшая и написана в виде художественного романа, что добавляет интереса. Обязательно возьмите ее с собой в поезд или самолет, или просто прочитайте вечером перед сном, как сделал я.

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

-