Архитектура ИТ решений. Часть 2. Архитекторы

С предыдущей частью статьи можно ознакомиться, перейдя по ссылке

III ОПРЕДЕЛЕНИЕ ПОНЯТИЯ АРХИТЕКТОР

Врач может похоронить свою ошибку, архитектор – разве что обсадить стены плющом. Фрэнк Ллойд Райт.
Зачастую в ИТ отрасли, говоря об ИТ архитекторе, подразумевают продвинутого разработчика, способного самостоятельно спроектировать, а главное реализовать большую сложную систему. А иногда попросту полагают, что это следующая ступенька в профессиональной иерархии разработчиков. Например, начал молодой специалист свою карьеру разработчика, ему присвоили скромное, но почетное звание Junior. Он учится, развивается профессионально, растет над собой и коллегами, и ему, в качестве компенсации за труд и упорство, торжественно присваивается звание Middle. Но он неугомонный и дальше не останавливается в развитии, совершает ряд подвигов, самоотверженно взвалив на себя ответственность за принимаемые решения. Глядишь, и его уже удостаивают высочайшего звания Sinior. А дальше? А если он не желает почивать на лаврах успеха и хочет развиваться, ему что присвоят под звуки фанфар генеральское звание Архитектора? Так ли это? Специально ИТ архитекторов, насколько мне известно, не готовят в вузах. Чаще всего архитекторы получаются путем селекции из уже маститых специалистов в какой-либо ИТ области, «прокачивая» дополнительными знаниями до определенного уровня. Кстати существует профессиональный стандарт квалификационных требований системных архитекторов (5), на основании которых архитектору может быть присвоен один из шести квалификационных уровней. Будем использовать этот стандарт в ходе нашего рассмотрения темы, чтобы не упустить ничего важного в работе ИТ архитектора. ...Далее...

Где найти и как выбрать тимлида



Предыстория


Привет! Меня зовут Виталий Шароватов, я уже 16 лет работаю в IT. Сейчас я руковожу направлением фронтенд в Badoo. В него входят две команды, которые занимаются разработкой и поддержкой десктопной версии сайта badoo.com, мобильной версии m.badoo.com и многими другими проектами. Да, десктопную и мобильную версии у нас делают отдельные команды. :)

Два с половиной года назад я пришел в Badoo разработчиком, со временем вырос до тимлида, а потом, когда было решено перевозить команду Desktop Web в Лондон, стал руководителем направления.

Прошлой осенью на Codemotion Milan я делал доклад о росте из разработчика в тимлида (и писал на Хабр статью об этом) и о том, с какими неожиданными моментами мне пришлось столкнуться, а теперь расскажу, как при переходе из лида в руководителя направления я справился с подбором и «выращиванием» тимлида в одной из команд (Mobile Web).
Читать дальше →

Ты и я не можем работать вместе

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

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

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

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

Юнит-тесты. Быстрый старт – эффективный результат (с примерами на C++)



Вместо вступления


Всем привет!
Сегодня хотелось бы поговорить о том, как просто и с удовольствием писать тестируемый код. Дело в том, что в нашей компании мы постоянно контролируем и очень ценим качество наших продуктов. Еще бы – ведь с ними ежедневно работают миллионы человек, и для нас просто недопустимо подвести наших пользователей. Только представьте, наступил срок сдачи отчетности, и вы тщательно и с удовольствием, используя заботливо разработанный нами пользовательский интерфейс СБИС, подготовили документы, еще раз перепроверили каждую циферку и вновь убедились, что встречи с вежливыми людьми из налоговой в ближайшее время не будет. И вот, легким нажатием мыши кликаете на заветную кнопку «Отправить» и тут БАХ! приложение вылетает, документы уничтожаются, жарким пламенем пылает монитор, и кажется, люди в погонах уже настойчиво стучат в двери, требуя сдачи отчетности. Вот как-то так все может и получиться:
Читать дальше →

[Из песочницы] Очевидное благо: как и зачем использовать сервисный подход за рамками ИТ

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


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

Не бойтесь терять ключевых разработчиков

В заголовок вынесена фраза из неоднозначной статьи менеджера проекта Яндекс.Здоровье «Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы». Опубликованная вчера в блоге Яндекса статья, оставляет неприятное послевкусие и вызвала множество критических комментариев. Полностью один из тезисов автора звучит так:

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

Архитектура ИТ решений. Часть 1. Архитектура предприятия

I ВСТУПЛЕНИЕ

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

Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы

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

#Ускорение4X. Кастомизация целей команды

Генеральные цели перехода на #Ускорение4X мы обсудили. Теперь нужно сделать еще более важную штуку — учесть цели каждого участника команды. Мы же ускоряемся сами для себя, а не для начальника. Кстати, спасибо, что заминусовали публикацию про генеральные цели. Минусы освобождают от необходимости пытаться вам понравиться, т.е. от зла. Остается чистое намерение дать информацию. Чем и займусь. Итак, зачем кастомизировать цели? Вроде нормально они звучат — ускориться, научиться работать на форсаже, научиться переводить на форсаж. Неприятность в том, что цели звучат слишком нормально. Банально звучат, пошло и неискренне. И в них не слышно ничего вашего. Вам как будто опять ставят чужую цель, и говорят, что вы должны хотеть ее достичь. Такое сплошь и рядом есть во всех компаниях, от всех собственников и менеджеров. Что они там обычно говорят? Давайте увеличим продажи вдвое! Наша цель — войти в список Forbes! Мы хотим через 5 лет выйти на IPO! Наша цель — 5 новых продуктов через год! Ну и т.д. Еще там непонятные миссии добавляются,ценности сейчас модно стало писать, и подобную ересь. Что с ними не так, вы уже понимаете — там нет вас. Ни про вас, ни для вас, ни про ваше будущее. Вы как были винтиком, шпунтиком или целой шестеренкой, а может быть редуктором/мультипликатором, так и останетесь, пока не выкинут, или сами не уйдете. Никому нет до вас никакого дела. Все корпоративные культуры — искусственная хрень, все похлопывания шефа по плечу — прием из книги по менеджменту (вроде ...Далее...

[Перевод] Питер Хинченс: Психология архитектуры программного обеспечения

Один из принципов Социальной Архитектуры заключается в том, что способ нашей организации важнее того, кем мы являемся.
imageДиркжан Октман (Dirkjan Ochtman) обратил мое внимание на определение архитектуры программного обеспечения в Википедии: «совокупность структур, требуемых для понимания системы, которая объединяет элементы программного обеспечения, связи между ними и их принадлежность». Для меня эта бессодержательная и цикличная болтовня служит хорошим примером того, как унизительно мало мы знаем о том, что на самом деле важно при создании масштабной архитектуры программного обеспечения. Архитектура — это искусство и наука создания крупных искусственных структур, используемых человеком. Если я что и понял и успешно применял на протяжении тридцати лет при создании все более крупных систем программного обеспечения, так это то, что программное обеспечение — это все о людях. Крупные структуры сами по себе бессмысленны. Важно то, как они функционируют для использования их людьми. А в программном обеспечении, человеческое начинается с программистов, которые делают его. Основные проблемы в архитектуре программного обеспечения кроются в человеческой психологии, а не в технологиях. Наша психология по-разному может влиять на нашу работу. Я могу привести примеры того, как группа людей словно становится глупее по мере того, как она расширяется, или когда им приходится работать, будучи разделенными огромным расстоянием. Значит ли это, что чем меньше команда, тем она эффективней? Как же тогда такое крупное глобальное сообщество как ZeroMQ умудряется успешно работать? ...Далее...


Последние посты