по следам 7го ITtalk

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

Шахтар ЧЕМПІОН

Шахтар виграв Кубок УЄФА! Слава Україні!

Graph framework for Java web UI

а не посоветуют ли благородные доны какую-нибудь готовую Open Source реализацию Java framework для построения графов? мне нужен самый простой функционал -- возможность формирования модели и отображение этой модели в web UI. желательно, каким-нибудь более современным способом, чем Applet. поиска путей, опитимизации путей и прочей математики не требуется. про yWorks и ILOG я знаю, но во-первый, денег на коммерческие компоненты у проекта нет, во-вторых, компоненты содержат слишком много излишнего функционала, за который никто платить не захоче.
вот такие дела.

Java & Active Directory

кратенькая заметка о том, как легко и непринужденно сделать single sign on в Java web приложении для серверов, включенных в домен Windows (Samba) Active Directory.
минимально необходимая библиотека jCIFS. настройки по интеграции достаточно просты и для самого простого случая достаточно минимальных, описанных на сайте. логин и пароль для Samba можно не указывать. в этом случае приложение напишет в логи сообщение, что Samba может работать не корретно, но в целом процедура авторизации работает.
также понадобится настройка браузера
Internet Explorer
достаточно включить опцию Internet Options -> Advanced -> Security -> Enable Integrated Windows Authentication
Firefox
1. откройте Firefox
2. загрузите url about:config
3. перечислите через запятую адреса серверов для следующих параметров
network.automatic-ntlm-auth.trusted-uris
network.negotiate-auth.delegation-uris
network.negotiate-auth.trusted-uris
Opera
википедия говорит, что с 9 версии прозрачная аутентификация поддерживается. никаких дополнительных настроек никто не предлагает. я не проверял, поэтому прийдется принять этот факт на веру и проверить на практике.
Safari
опять таки, доподлинно не известно, работает ли аутентификация в Safari on Windows, кое-где есть ссылки, что не рабоает. иначе говоря, как и для Оперы нужно проверять.
Google Chrome и прочие
да простят меня фанаты Chrome, но на текущий момент это еще бОльшая экзотика, чем Опера или Сафари, так что здесь я предлагаю фанатам проверить совместимость самим :)

итоги года

год уходящий был сложен и в тоже время более чем продуктивен. на первый план в году уходящем, с самого его начала, вышли проблемы, к профессиональной деятельности отношения не имеющие. огромное спасибо всем, кто поддержал меня в трудную минуту испытаний, благодаря всем вам я сохранил ясность рассудка, желание жить, трудиться и созидать разумное, доброе, вечное.
в профессиональной сфере год 2008й ознаменовался прежде всего тем, что мне удалось примерить фуражку начальник отдела, вплотную заняться управлением сначала ресурсами, а потом и проектами. довольно долгий период времени это была моя цель, к которой я подходил может быть даже слишком долго. результатами своей деятельности я доволен, хотя без ошибок тут не обошлось. однако, что не убивает нас, то делает нас сильнее. я бы рекомендовал все програмистам, уровня Senior Developer, попробовать себя в роли менеджеров официально или не официально в данном случае значения не имеет. но роль управленца в проекте или подпроетке очень здорово прочищает мозги и позволяет взглянуть на знакомую и рутинную работу под новым углом. заниматься ли управление дальше? это каждый рещи сам, но опыт в управлении поистине бесценен, да и в резюме будет смотреться не лишним.
так уж получилось, что в свою предыдущую компанию я пришел исключительно в порядке эксперимента, можно сказать даже авантюры. прежде всего мне понравились люди, которым предстояло стать моими начальниками. и я не ошибся. это были прекрасные месяцы работы в слаженном коллективе, с взаимопонимаем, единой целью и четким путем ее достижения. спасибо огромное, ребята.
однако, все проходит, так или иначе, но пути моих предыдущих начальников увели их прочь из конторы. до осени я еще пытался эксперемнировать на предыдущем месте, хотя делать это становилось все сложнее и понимание того, что мои инициативы никому, кроме меня, не нужны становилось все яснее. осенью грянул кризис и время для экспериментов кончилось. я довольно удачно сменил работу и ожидаю новых и приятных впечатление от нового места и новых людей.
несмотря на неблагоприятные прогнозы, я искрене верю в то, что кризис это прежде всего новые возможности. возможности личного и профессионального роста; возможности начать делать то, что давно следовало; возможности изменить себя и свою жизнь; возможности стать лучше, честнее, отвественнее, профессиональнее, человечнее, добрее, терпимие. я верю, что кризис принесет миру обновление, которое в конечном итоге пойдет миру на пользу.
так что в новом, 2009м году, желаю всем вам мира, добра и достатка. желаю, что бы каждый из вас смог увидеть возможность измениться к лучшему самому и изменить к лучшему мир вокруг и этой возможностью воспользовался.
с Новым 2009м Годом!

relationship: employer & employee

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

Warranty

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

Роман Хмиль о настоящем и будущем украиского ИТ

данная статья цитируется по материалам обсуждения сайта developers.org.ua с разрешения всех заинтересованных сторон.
вопросы подготовлены пользователем realist, отвечает Роман Хмиль, CEO Global Logic Ukraine.
(с) realist, 02/08/2008
(c) Роман Хмиль AKA Romki, 03/08/2008

итоги подведем

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

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


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


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


4. публикация задач, включающая информацию о estimated & spend time, start & due date... позволяет всем stakeholders отслеживать состояние задач


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


6. ежедневная сборка проекта для тестирования. лучше 2 раза в день, хуже -- один

еще один холодный день в аду

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