Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2014

Матрица компетентности программистов

Computer Science   2n (Level 0) n2 (Level 1) n (Level 2) log(n) (Level 3) Comments data structures Doesn't know the difference between Array and LinkedList Able to explain and use Arrays, LinkedLists, Dictionaries etc in practical programming tasks Knows space and time tradeoffs of the basic data structures, Arrays vs LinkedLists, Able to explain how hashtables can be implemented and can handle collisions, Priority queues and ways to implement them etc. Knowledge of advanced data structures like B-trees, binomial and fibonacci heaps, AVL/Red Black trees, Splay Trees, Skip Lists, tries etc.   algorithms Unable to find the average of numbers in an array (It's hard to believe but I've interviewed such candidates) Basic sorting, searching and data structure traversal and retrieval algorithms Tree, Graph, simple greedy and divide and conquer algorithms, is able to understand the relevance of the levels of this matrix. Able to recognize and code dynamic programming solutions, good knowledge of graph algorithms, good knowledge of numerical computation algorithms, able to identify NP problems etc. Working with someone who has a good topcoder ranking would be an unbelievable piece of luck! systems programming Doesn't know what a compiler, linker or interpreter is Basic understanding of compilers, linker and interpreters. Understands what assembly code is and how things work at the hardware level. Some knowledge of virtual memory and paging. Understands kernel mode vs. user mode, multi-threading, synchronization primitives and how they're implemented, able to read assembly code. Understands how networks work, understanding of network protocols and socket level programming. Understands the entire programming stack, hardware (CPU + Memory + Cache + Interrupts + microcode), binary code, assembly, static and dynamic linking, compilation, interpretation, JIT compilation, garbage collection, heap, stack, memory addressing...   Software Engineering   2n (Level 0) n2 (Level 1) n (Level 2) log(n) (Level 3) Comments source code version control Folder backups by date VSS and beginning CVS/SVN user Proficient in using CVS and SVN features. Knows how to branch and merge, use patches setup repository properties etc. Knowledge of distributed VCS systems. Has tried out Bzr/Mercurial/Darcs/Git   build automation Only knows how to build from IDE Knows how to build the system from the command line Can setup a script to build the basic system Can setup a script to build the system and also documentation, installers, generate release notes and tag the code in source control   automated testing Thinks that all testing is the job of the tester Has written automated unit tests and comes up with good unit test cases for the code that is being written Has written code in TDD manner Understands and is able to setup automated functional, load/performance and UI tests   Programming   2n (Level 0) n2 (Level 1) n (Level 2) log(n) (Level 3) Comments problem decomposition Only straight line code with copy paste for reuse Able to break up problem into multiple functions Able to come up with reusable functions/objects that solve the overall problem Use of appropriate data structures and algorithms and comes up with generic/object-oriented code that encapsulate aspects of the problem that are subject to change.   systems decomposition Not able to think above the level of a single file/class Able to break up problem space and design solution as long as it is within the same platform/technology Able to design systems that span multiple technologies/platforms. Able to visualize and design complex systems with multiple product lines and integrations with external systems. Also should be able to design operations support systems like monitoring, reporting, fail overs etc.   communication Cannot express thoughts/ideas to peers. Poor spelling and grammar. Peers can understand what is being said. Good spelling and grammar. Is able to effectively communicate with peers Able to understand and communicate thoughts/design/ideas/specs in a unambiguous manner and adjusts communication as per the context This is an often under rated but very critical criteria for judging a programmer. With the increase in outsourcing of programming tasks to places where English is not the native tongue this issue has become more prominent. I know of several projects that failed because the programmers could not understand what the intent of the communication was. code organization within a file no evidence of organization within a file Methods are grouped logically or by accessibility Code is grouped into regions and well commented with references to other source files File has license header, summary, well commented, consistent white space usage. The file should look beautiful.     2n (Level 0) n2 (Level 1) n (Level 2) log(n) (Level 3) Comments code organization across files No thought given to organizing code across files Related files are grouped into a folder Each physical file has a unique purpose, for e.g. one class definition, one feature implementation etc. Code organization at a physical level closely matches design and looking at file names and folder distribution provides insights into design   source tree organization Everything in one folder Basic separation of code into logical folders. No circular dependencies, binaries, libs, docs, builds, third-party code all organized into appropriate folders Physical layout of source tree matches logical hierarchy and organization. The directory names and organization provide insights into the design of the system. The difference between this and the previous item is in the scale of organization, source tree organization relates to the entire set of artifacts that define the system. code readability Mono-syllable names Good names for files, variables classes, methods etc. No long functions, comments explaining unusual code, bug fixes, code assumptions Code assumptions are verified using asserts, code flows naturally - no deep nesting of conditionals or methods   defensive coding Doesn't understand the concept Checks all arguments and asserts critical assumptions in code Makes sure to check return values and check for exceptions around code that can fail. Has his own library to help with defensive coding, writes unit tests that simulate faults     2n (Level 0) n2 (Level 1) n (Level 2) log(n) (Level 3) Comments error handling Only codes the happy case Basic error handling around code that can throw exceptions/generate errors Ensures that error/exceptions leave program in good state, resources, connections and memory is all cleaned up properly Codes to detect possible exception before, maintain consistent exception handling strategy in all layers of code, come up with guidelines on exception handling for entire system.   IDE Mostly uses IDE for text editing Knows their way around the interface, able to effectively use the IDE using menus. Knows keyboard shortcuts for most used operations. Has written custom macros   API Needs to look up the documentation frequently Has the most frequently used APIs in memory Vast and In-depth knowledge of the API Has written libraries that sit on top of the API to simplify frequently used tasks and to fill in gaps in the API E.g. of API can be Java library, .net framework or the custom API for the application frameworks Has not used any framework outside of the core platform Has heard about but not used the popular frameworks available for the platform. Has used more than one framework in a professional capacity and is well-versed with the idioms of the frameworks. Author of framework     2n (Level 0) n2 (Level 1) n (Level 2) log(n) (Level 3) Comments requirements Takes the given requirements and codes to spec Come up with questions regarding missed cases in the spec Understand complete picture and come up with entire areas that need to be speced Able to suggest better alternatives and flows to given requirements based on experience   scripting No knowledge of scripting tools Batch files/shell scripts Perl/Python/Ruby/VBScript/Powershell Has written and published reusable code   database Thinks that Excel is a database Knows basic database concepts, normalization, ACID, transactions and can write simple selects Able to design good and normalized database schemas keeping in mind the queries that'll have to be run, proficient in use of views, stored procedures, triggers and user defined types. Knows difference between clustered and non-clustered indexes. Proficient in use of ORM tools. Can do basic database administration, performance optimization, index optimization, write advanced select queries, able to replace cursor usage with relational sql, understands how data is stored internally, understands how indexes are stored internally, understands how databases can be mirrored, replicated etc. Understands how the two phase commit works.   Experience   2n (Level 0) n2 (Level 1) n (Level 2) log(n) (Level 3) Comments languages with professional experience Imperative or Object Oriented Imperative, Object-Oriented and declarative (SQL), added bonus if they understand static vs dynamic typing, weak vs strong typing and static inferred types Functional, added bonus if they understand lazy evaluation, currying, continuations Concurrent (Erlang, Oz) and Logic (Prolog)   platforms with professional experience 1 2-3 4-5 6+   years of professional experience 1 2-5 6-9 10+   domain knowledge No knowledge of the domain Has worked on at least one product in the domain. Has worked on multiple products in the same domain. Domain expert. Has designed and implemented several products/solutions in the domain. Well versed with standard terms, protocols used in the domain.   Knowledge   2n (Level 0) n2 (Level 1) n (Level 2) log(n) (Level 3) Comments tool knowledge Limited to primary IDE (VS.Net, Eclipse etc.) Knows about some alternatives to popular and standard tools. Good knowledge of editors, debuggers, IDEs, open source alternatives etc. etc. For e.g. someone who knows most of the tools from Scott Hanselman's power tools list. Has used ORM tools. Has actually written tools and scripts, added bonus if they've been published.   languages exposed to Imperative or Object Oriented Imperative, Object-Oriented and declarative (SQL), added bonus if they understand static vs dynamic typing, weak vs strong typing and static inferred types Functional, added bonus if they understand lazy evaluation, currying, continuations Concurrent (Erlang, Oz) and Logic (Prolog)   codebase knowledge Has never looked at the codebase Basic knowledge of the code layout and how to build the system Good working knowledge of code base, has implemented several bug fixes and maybe some small features. Has implemented multiple big features in the codebase and can easily visualize the changes required for most features or bug fixes.   knowledge of upcoming technologies Has not heard of the upcoming technologies Has heard of upcoming technologies in the field Has downloaded the alpha preview/CTP/beta and read some articles/manuals Has played with the previews and has actually built something with it and as a bonus shared that with everyone else     2n (Level 0) n2 (Level 1) n (Level 2) log(n) (Level 3) Comments platform internals Zero knowledge of platform internals Has basic knowledge of how the platform works internally Deep knowledge of platform internals and can visualize how the platform takes the program and converts it into executable code. Has written tools to enhance or provide information on platform internals. For e.g. disassemblers, decompilers, debuggers etc.   books Unleashed series, 21 days series, 24 hour series, dummies series... Code Complete, Don't Make me Think, Mastering Regular Expressions Design Patterns, Peopleware, Programming Pearls, Algorithm Design Manual, Pragmatic Programmer, Mythical Man month Structure and Interpretation of Computer Programs, Concepts Techniques, Models of Computer Programming, Art of Computer Programming, Database systems , by C. J Date, Thinking Forth, Little Schemer   blogs Has heard of them but never got the time. Reads tech/programming/software engineering blogs and listens to podcasts regularly. Maintains a link blog with some collection of useful articles and tools that he/she has collected Maintains a blog in which personal insights and thoughts on programming are shared   Источник

Categories: Development | Management
Posted by Vitalii Tsybulnyk on Wednesday, October 10, 2012 5:50 AM
Permalink | Comments (1) | Post RSSRSS comment feed

О какающих птичках и иерархии руководства в Microsoft

Когда в предыдущем посте я похвастался своей новой руководящей должностью в Microsoft, некоторые заботящиеся о моей карме читатели посоветовали побольше внимания уделять чёрным полосам моей жизни, в частности какающим на голову птичкам. Тут как нельзя кстати вспомнилась старая, но от этого не менее забавная и не менее правдивая диаграмма типичной иерархии руководителей и подчинённых в крупных компаниях:   В этой связи мне кажется весьма уместным перечислить всю иерархию руководящих позиций в Microsoft, дабы стало понятно что количество какающих на менеджера первого уровня птичек не намного меньше, чем на среднестатистического роботягу. Итак, сверху вниз: * CEO - исполнительный глава компании * Президенты (President) возглавляют 7 бизнесов (Business) компании, например 'Windows', 'Online Services', 'Server and Tools', и т.п. * Вице-Президенты (Vice President) возглавляют подразделения (Division), или группы продуктов, например 'Server and Cloud' для серверных продуктов, 'Development Division' для средств разработки и т.п. * По старой иерархии, дальше шло деление на менеджеров продуктов (Product Unit Manager или General Manager) , и такое деление ещё сохранилось в некоторых дивижнах, но вцелом тенденция движется в сторону деления по директорам.   По новой иерархии, Директора (Director) возглавляют функциональные ветки разработки продукта, например Director of Developemnt, Director of Test, Director of Program Management и т.п. * Менеджеры функциональных групп, например Development Manager, Test Manager, Group Program Manager подчиняются директорам и возглавляют несколько команд сходного направления. * Руководители команд (Lead) подчиняются менеджерам групп по фунциям (Development Lead, Test Lead, и т.п.) и являются наинизшим уровнем руководящих позиций в Microsoft. * Простые роботяги (Individual Contributor) не руководят никем и могут подчиняться любому из вышеперечисленных менеджеров, в зависимости от уровня и важности работника, например девелоперы и тесты в большинстве подчиняются руководителю команды (Lead), а  скажем архитекторы как правило подчиняются менеджеру более высокого ранга. Любой их вышеперечисленных типов менеджеров может присутствовать в иерархии дважды, например один Lead подчиняется другому, а тот уже Group Manager'у, или VP подчиняется Senior VP, т.е. реальные иерархии почти всегда более глубокие чем то что я перечислил. Таким образом, в Microsoft даже есть ироничный способ измерения позиции сотрудника в "шагах от Стива Балмера". Среднестатистический сотрудник находится в семи шагах от Балмера, т.е. в руководящей иерархии между ним и CEO шесть других менеджеров. Ну вот теперь вы знаете всё о птичках, вы можете предствить, вот ту картинку вначале поста применительно к Microsoft :-)

Categories: Management | Microsoft
Posted by Vitalii Tsybulnyk on Tuesday, March 27, 2012 5:56 PM
Permalink | Comments (6) | Post RSSRSS comment feed

Руководитель команды разработчиков в Microsoft

На этой неделе произошло важное событие в моей профессиональной жизни, которым я не могу не похвастаться поделиться: меня официально повысили по должности до руководителя команды разработчиков (Software Development Lead). Не буду скрывать, для меня это важнейшее достижение не только в Microsoft, но и во всей профессиональной карьере, и тому есть множество причин, о которых я и попытаюсь рассказать. Software Development Lead в Microsoft. Для того, чтобы лучше раскрыть суть должности Development Lead, стоит упомятнуть что в Microsoft две карьерных лесницы - individual contributor и manager, которые идут параллельно друг другу, и одинаково почётны и важны в компании. Individual contributor - это технический специалист, например девелопер или тестировщик, а manager - это руководитель команд разработчиков/тестировщиков. Должность Development Lead в Microsoft - это руководитель (менеджер) первого уровня, то есть менеджер, в подчинении которого только individual contributorы, а не другие менеджеры. "Lead" в названии должности может несколько сбить с толку представителей пост-советского пространства, где лидами принято называть технического лидера команды, не выполняющего функции менеджмента проекта и персонала. Development Lead в Microsoft выполняет как функции technical leadership, так и people management, включая вИдение проекта, планирование, ключевые технические решения, а также вЕдение карьеры подчинённых, решение о найме и увольнении, уровне зарплаты и бонуса и т.п.   Как стать Software Development Lead в Microsoft? Для того чтобы стать менеджером команды в Microsoft, нужно прежде всего обладать множеством разнообразных качеств: problem solving skills, technical knowlege, comminication skills, leadership, decision making, vision, и т.п. Кроме того, у компании должна быть необходимость в руководителе команды, что даёт три варианта: 1) Образовывается совершенно новая команда, куда нанимают совершенно нового руководителя - этот способ мне кажется самым сложным, так как в новую команду как правило берут человека с проверенным многолетним опытом руководителя команд в самом Microsoft или компании такого же уровня 2) Руководитель существующей команды покидает свою должность и нужен новый руководитель - этот способ мне кажется самым непредсказуемым, т.к. целиком опирается на не зависящее от тебя решение другого человека, и можно годами ждать такой возможности 3) Команда/проект растут до тех пор, пока не возникает необходимость в разбиении её на несколько команд со своими руководителями - этот способ тоже во многом зависит от удачи, но у тебя есть возможность хотябы учавствовать непосредственно в успехе и росте твоего проекта, чтобы когда он потребует больше людей, ты оказался лучшим кандидатом на роль руководителя. В общем картина такова, что Microsoft предпринимает много шагов для того, чтобы сильные сотрудники имели пространство для карьерного роста, но для руководящих должностей всё-таки немалую роль играет и стечение обстоятельств, и бизнес-климат в виде новых проектов и новых команд. Как я стал Software Development Lead в Microsoft. Чуть больше чем полтора года назад я перешёл из Visual Studio в Windows Azure, сравнительно молодой и растущий продукт компании. Моя команда занималась несколькими направлениями, и успех или провал любого из них был непредсказуем. Я "приложил руку" в паре таких направлений, и после года работы одно из них стало набирать обороты и потребовало участия нескольких людей. Я сначала учавствовал как рядовой разработчик, но со временем мне удалось зарекомендовать себя и приобрести некоторый авторитет, и меня стали представлять техническим лидером проекта. Ещё через пол года в роли исполняющего обязанности лида, моим менджером было принято решение об официальной реструктуризации этого проекта в отдельную команду с вашим покорным слугой во главе. Что дальше? Конечно же, я сейчас очень польщён и горд таким признанием своих профессиональных и лидерских качеств, но эмоции скоро пройдут, а остаётся огромная ответственность. Ответственность не только за успех проекта, ведь приходится решать самые сложные за всю мою профессиональную карьеру технические проблемы, которые никто до меня не решил (а если и решил, то не скажет как). Отвественность не только за продукт, который в последнее время приобретает ведущую роль и как в компании, как и во всей индустрии. Теперь это ещё и отвественнось за тех людей, карьера и профессиональная судьба которых во многом зависит от меня, моей способности привести проект и свою команду к успеху, моих умений дать каждому члену своей команды реализоваться и вырости как специалисту, и что даже более важно, создать атмосферу когда каждый с радостью идёт утром на работу. И ответсвенность эта вдвойне усиливается тем, что эти люди - сильнейшие представители своей профессии, звезды первой величины, выпускники Стенфорда, Ватерлу, и Карнеги-Мелон, с невероятной работоспособностью и потрясающим потенциалом. Именно поэтому среди нас нет начальников и подчинённых, есть партнёры с разной ролью, и моя роль теперь - эта величайшая ответственность, и одновременно огромная честь вести нас к общему успеху.

Posted by Vitalii Tsybulnyk on Thursday, March 22, 2012 8:46 AM
Permalink | Comments (8) | Post RSSRSS comment feed

Как зарегистрировать свою компанию в США

К концу 2010-го года у меня и моей жены Аллы назрела целесообразность регистрации собственной компании в американском штате Вашингтон, где мы живём и работаем.   Подоплёкой этого решения было следующее:    • С 2008-го года Алла активно занималась фрилансом, разрабатывая веб-проекты для американских и канадских заказчиков. Однако летом 2010-го года ей предложили контрактную работу в Майкрософт на полный день, и всё её время и силы стали уходить туда, и к работе над существующими на тот момент фриланс проектами пришлось удалённо привлекать других фрилансеров с просторов пост-советского пространства. Работа Аллы (и немного моя) минимизировалась до общения с заказчиком, формулирования требований и сроков, технического курирования работ и релиз-менеджмента.    • У меня зрела парочка идей по разработке собственных программных продуктов и сервисов, хотя времени и ресурсов на их реализацию пока не хватало.   Наличие официально зарегистрированной компании должно было дать следующие преимущества:    • Вес в глазах заказчиков: наличие официально зарегистрированной компании должно было помочь в случае решения о привлечении новых заказчиков и проектов.    • Гибкость: общение с заказчиком можно вести от лица компании, а значит в случае загруженности Аллы (или других обстоятельств) общение с закачиком мог продолжать вести любой из партнёров-совладельцев компании, или даже в перспективе специально нанятый для этого менеджер.    • Вес в глазах наёмных сотрудников: в случае решения о привлечении новых заказчиков и проектов, наличие компании со своим видением, портфелем заказов и штатом консультантов может в перспективе помочь в долговременном привлечении толковых разработчиков.    • Оптимизация налогообложения: наличие официальной компании упрощает декларирование затрат при работе над проектом (в виде вознаграждения удалённым консультантам и т.п.), таким образом в налогообложении участвует только чистая прибыль.    • Брэнд: в случае разработки и выпуска собственных программных продуктов, наличие компании могло бы помочь обеспечить им общий юридический брэнд.   Когда решения о регистрации было принято, и я занялся этим вопросом, то сам процесс оказался удивительно быстрым и безболезненным. Вся процедура заняла около 2-3 недель и свелась для нас к следующим шагам:    • Выбору названия и типа компании.    • Нахождению (методом поиска в онлайн) компании, оказывающей услуги по регистрации выбранного нами типа компании в нашем штате.    • Предоставлении компании-регистратору (методом заполнения онлайн форм и отправления по почте их твёрдых копий заверенных нашими подписями) всех необходимых данных о будущей компании (тип, название, род деятельности и юридический адрес) и ее основателях (имя, идентификационный код, почтовый адрес, телефон).    • Оплата услуг компании-регистратора (методом онлайн-платежа) в размере около $400, уже включающей в себя платёж государственным органам в размере около $200.    • Получение по почте от государственных огранов готового сертификата о регистрации и праве обладания компанией. Таким образом в декабре 2010-го года мы с Аллой стали гордыми основателями и владельцами собственной американской софтверной компании  (тип компании: LLC). Повторюсь, вся процедура:  - прошла не выходя из дома;  - обошлась в $400 и около часа времени на заполнение необходимых форм;  - заняла по времени меньше месяца.   Дальнейшее поддержание статуса компании включает в себя:    • Своевременную ежегодную декларацию доходов и уплату налогов (причём декларация о доходах компании просто включается в нашу с Аллой персональную декларацию о доходах).    • Уплату государственному органу платежа в размере $70 в год за ежегодное продление статуса компании.

Categories: Management
Posted by Vitalii Tsybulnyk on Saturday, June 25, 2011 7:34 AM
Permalink | Comments (3) | Post RSSRSS comment feed

Контроль or not контроль?

Том ДеМарко не нуждается в отдельном представлении, на его книгах выросло не одно поколение руководителей и разработчиков, вот лишь некоторые их этих книг: 1986. Controlling Software Projects: Management, Measurement, and Estimates. Prentice Hall 1987. Peopleware: Productive Projects and Teams. With Timothy Lister. Dorset House. 1997. The Deadline: A Novel About Project Management. Dorset House. 2003. Waltzing with Bears: Managing Risk on Software Projects. With Tim Lister. Dorset House in March, 2003. Контроль над протеканием проектов разработки ПО - одна из ключевых тем его работ. Именно ему принадлежит ставшая крылатой фраза "You can’t control what you can’t measure" ("Вы не можете контролировать то, что невозможно измерить"). Однако сегодня лично мне очень приятно наблюдать, как этот действительно умный и талантливый человек меняет свою точку зрения на аспекты контроля вместе с изменением видения всего процесса в ИТ индустрии. Этот человек не боится признать, что был не прав, и статья [1] полностью посвящена такому признанию. Вот что он пишет: Моя ранняя книга по метрикам 'Controlling Software Projects: Management, Measurement, and Estimation' (Prentice Hall/Yourdon Press, 1982) сыграла важную роль в том, как многие инженеры-разработчики измеряли свою работу и планировали проекты. Под настроением провести некоторую рефлексию я спрашиваю себя: были бы мои советы в силе и сейчас, спустя столько времени? Верю ли я сам всё ещё, что метрики являются обязательным аспектом успешного процесса разработки ПО? Мой ответ: нет, нет и нет. По собственному признанию, Том не учитывал в своих работах о метриках многих важных и очевидных сегодня вещей: - не все метрики одинаково хороши и нужны- сбор качественных метрик стоит дорого (время, ресурсы)- метрики должны использоваться осторожно- разработка ПО отличается от естественных наук и её метрики намного менее точны в их попытке измерить те вещи, которые они должны отражать. Основной мыслью работ ДеМарко о метриках всегда было то, что контроль является пожалуй самым важным аспектом любого проекта по разработке ПО. Однако он сам признаёт сейчас, что это не так. Для понимания настоящей роли контроля, нужно различать два совершенно разных типа проектов:  - проект А при вложениях X приносит выгоду/прибыль 1.1*X- проект Б при вложениях X приносит выгоду/прибыль 50*X Очевидно, что контроль очень важен для проекта А и практически совершенно не важен для проекта Б. Это приводит нас к странному выводу, что строгий контроль очень важен для сравнительно бесполезных проектов и менее важен для полезных. Чем больше вы сосредотачиваетесь на контроле, тем более вероятно, что вы работаете над проектом, результирующая ценность которого сравнительно мала. Значит ли это, что можно успешно запускать проекты без особенного контроля? Вот что пишет ДеМарко:  Практически, да. Сначала выберите проект, в котором точный контроль не был бы так важен. Затем снизьте свои ожидания о том, как сильно вы сможете его контролировать. Как же управлять проектом без контроля? Руководите людьми и контролируйте время и деньги. Например, вы можете сказать своим тим-лидам: “У меня есть на уме дата окончания, но я даже не собираюсь вам её сообщать. Когда однажды я прийду и скажу, что проект заканчивается через неделю, вы должны быть готовы всё собрать и выпустить то, что у вас будет на тот момент как финальный продукт. Ваша задача - работать над проектом инкрементно, добавляя кусочки к целому в порядке их важности, и выполняя интерграцию, документирование и приёмочное тестирование такими же этапами.” Это может выглядеть как рецепт гибких методологий, но я ... просто проедлагаю это как подход к управлению. Я постепенно прихожу к выводу что software engineering - это идея, время которой пришло и ушло... Этот термин делает акцент на определённом наборе дисциплин, включая предопределённый процесс, проверки и разборы результатов, разработка требований, матрицы traceability, метрики, детальный контроль качества, строгое планирование с последующим слежением, стандарты кодирования и документирования. Всё это в целях последовательости в практиках и предсказуемости. Последовательность и предсказуемость всё ещё желательны, но они никогда не были наиболее важными вещами. Например, последние 40 лет мы мучались своей неспособностью заканчивать софтверные проекты в срок и в рамках бюджета. Но, как уже намекалось выше, это никогда не должно было быть высшей целью. Более важной целью является трансформация: создание ПО, способного изменить этот мир, или компанию, или то, как она ведёт свой бизнес. Лучше бы мы старались преуспеть в этой трансформации, пусть даже действуя вне рамок нашего контроля. Разработка софта всегда была и остаётся в чём-то экспериментальной. Само создание ПО не обязательно экспериментально, но его концепция - да. И это то, где дожен быть наш фокус. Это то, где наш фокус должен был быть всегда.    Источники 1. Tom DeMarco Software Engineering: An Idea Whose Time Has Come and Gone?

Posted by Vitalii Tsybulnyk on Friday, November 26, 2010 6:49 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Команда vs. Методология

В своих заметках я часто обращаюсь к теме гибких методологий разработки: я уже рассказывал как о многих успешных практиках, так и о наиболее распространённых ошибках и антипаттернах, способных свести на нет все достоинства методологии или даже привести проект к провалу. Однако чем больше я об этом думаю, пишу, выслушиваю отзывы и анализирую реальные примеры, тем больше убеждаюсь, что детали реализации гибкой методологии и используемые практики играют не такую уж большую роль в успехе или провале проекта. Успешная команда приведёт проект к успеху с практически любой методологией. Удачно подобранная методология несомненно способна сделать этот успех ещё более внушительным. Неподходящая методология скорее всего ухудшит результат, одако это врядли окажет решающее влияние на судьбу проекта. Провальная команда провалит проект с практически любой методологией. Даже наилучшая методология врядли способна на большее, чем просто растянуть агонию или смягчить провал. Неподходящая методология ещё быстрее выявит провальные тенденции и станет впоследствии "козлом отпущения", на которого и свалят вину от провала. Успешность или провальность команды формируется из множества факторов, большинство из которых относится к социальной, а не технической сфере, что невероятно затрудняет их анализ и коррекцию. Это и мотивация, и межличностные отношения и коммуникации, и успешность формирования лидерства в команде, и наличие в команде всех необходимых для успеха ролей, и стадия формирования самой команды, и многое другое. Для "нейтрализации" всех этих факторов (или по крайней мере большинства) были разработаны так называемые "тяжёлые" методологии. Например, большинство требований к сертификации процесса по ISO 9001:2000 как раз сводится к нейтрализации "человеческих" факторов и подмены их тем, что принято называть бюрократией. Для провальных команд использование подобных процессов и методологий - единственных путь привести проект к успешному завершению пусть даже ценой десятикратных затрат времени и ресурсов. Для успешных команд использование подобных методологий - существенная потеря времени и ресурсов, устранение которой (переход на более "лёгкие" методологии) способно многократно повысить общую производительность и результирующую успешность. Именно применение в успешных командах и оптимизация с их помощью успешных команд является основным сектором использования гибких методологий. К сожалению, большинство авторов не делают на этом никакого акцента, в скорее наоборот, стараются "притянуть" свою методологию "за уши" в сторону всеобщей применимости. Последствия такой интерпретации - желание всё большего числа менеджеров внедрить гибкую методологию в своей не очень успешной команде, и решить тем самым проблемы её неуспешности. Только вот результат обычно обратный и не заставляет себя долго ждать: проблемы становятся ещё более явными, провал приближается ещё более стремительно, неудача в итоге "списывается" на методологию. В связи со всем вышесказанным, хочу посоветовать всем менеджерам, задумавшим переход/внедрение гибкой методологии: 1. Постарайтесь ответить себе честно - успешна ли ваша команда? Есть ли в её работе "провальные" тенденции? Если команда с трудом приводит к успеху половину проектов - задумайтесь об утяжелении процесса или о новой команде. Если успешность команды близка к 100% - это то что надо, пора становиться гибче. 2. Никогда не переходите на методологию в середине проекта, особенно если в нём назревают серьёзные проблемы. Идеальное время перехода - между проектами или в самом начале проекта. Лучше всего "обкатать" методологию на небольшом проекте и маленькой команде, потом уже запусткать на серьёзные проекты и всю компанию. Если переход в середине проектного цикла неизбежен, делайте это только во время относительного  спокойствия, решив сначала основные проблемы и уведя проект от кризисных тенденций. Ну и конечно же, всё вышесказанное никак не отменяет других советов по переходу, если решение о переходе всё-таки принято и процесс запущен.

Categories: Agile | Management
Posted by Vitalii Tsybulnyk on Wednesday, November 3, 2010 7:56 AM
Permalink | Comments (0) | Post RSSRSS comment feed

О готовности к повышению и парадоксе самооценки

Система служебных уровней и выдвигаемые для каждого уровня требования существенно разнятся от компании к компании и от одной специальности к другой, однако проблема определения и самоопределения уровня сотрудника согласно установленной леснице уровней была и будет всегда и везде. Если условно обозначить цифрами от 0 и далее уровень владения сотрудником определённой компетенцией, то получаем характерную картину, отражающую текущее состояние гипотетического сотрудника X по шкале уровней компании Y: Рис.1   Рис.1  Рис. 2 Под необходимыми сотруднику компетенциями разные компании и разные должности могут понимать совершенно разные вещи, например для девелоперов это обычно технические знания и умения, способности к решению проблем, скорость освоения новых технологий и т.п. Количество этих компетенций также очень сильно зависит от компании, например в Microsoft их 33 (из которых выделяют 6 основных), в компаниях поменьше с более узкой специализацией их может быть например 1-2. Под уровнями тоже в разных компаниях понимают разные вещи, в компаниях покрупнее уровень каждого сотрудника - формальная, известная сотруднику и его менеджеру цифра (или буква), в компаниях поменьше как правило просто выделяют Junior, Middle, Senior, но суть от этого не меняется. Проблему, которую я хотел бы обсудить в этом посте, наглядно демонстрирует Рис. 1: каков итоговый уровень сотрудника на этом графике? 1? 2? Ответ на этот вопрос далеко не однозначен и зависит как от политики компании, так и от конкретного менеджера, проводящего оценку сотрудника. Вопрос становится ещё более интригующим для ситуации на Рис. 2. В небольших компаниях ответ на этот вопрос обычно определяется как некое среднее от уровней владения всеми важными компетенциями, т.е. для небольшой компании на рисунках скорее всего показан сотрудних уровня 2. В компаниях типа Microsoft ответ как правило будет менее утешительным: формальный уровень сотрудника устанавливается на уровне самой слабой из учитываемых компетенций, т.е. на обоих рисунках показан сотрудник уровня 1. Пожалуй такие компании имеют право на такую политику - раз уж какая-то компетенция установлена как определяющая для роли - значит сотрудних должен обладать ею в опрелелённой мере, иначе выполнение задач подвергается риску, который компания не может и не хочет себе позволять. В совокупности с тем, что и количество учитываемых компетенций существенно больше, получаем существенное затруднение в карьерном росте. Однако у такого подхода есть и позитивная сторона: достигнув определённого уровня в небольшой компании, вы никогда не знаете что вас ждёт при переходе в другую. Например, Senior Developer в небольшом стартапе может оказаться Middle или даже Junior при переоде в другой, где система оценки другая. Если же определённый уровень достигнут в компании с большим числом компетенций и с оценкой "по наинизшему уровню" - можно быть спокойным что это уже гарантированняй уровнень при переходе как внутри, так и вне компании. При переходе же в небольшую компаню кровень как правило можно даже с лёгкостью повысить. Ситуация усугубляется ещё и тем, что я наблюдаю у 4-х из 5-ти сотрудников и называю парадоксом самооценки, который заключается в том, что человек как правило оценивает сам себя по наиболее сильной из своих компетенций. Например, сотрудник на Рис. 2, сравнивая себя с другими сотрудниками, наверняка считает себя достойным уровня 3, т.к. при сравнении он учитывает наиболее сильные ("любимые") свои компетенции. Этот парадокс часто приводит к недовольству сотрудника и имеет два решения: решение "снизу" и решение "сверху". Решение "снизу" - сотрудник просто переходит в компанию, где слабые компетенции не учитываются, и таким образом получает тот уровень, по которому оценивает себя сам. Решение "сверху" - компания делает систему оценок и набор компетенций максимально прозрачной для сотрудников, проводится работа по их разъяснению, а менеждер распределяет задачи и прикладывает усилия таким образом, чтобы развить именно слабые компетенции в каждом из сотрудников. К сожалению, решение "сверху" - это долгий и тяжёлый путь без гарантии успеха, далеко не все могут и хотят тратить время на его прохождение, а это уже древний, как сам человек парадокс: кем же лучше быть - живой собакой или мёртвым львом? При этом я и сам затрудняюсь сказать кто в данном случае собака, а кто лев - оставим это каждому для самооценки .

Categories: Management | Microsoft
Posted by Vitalii Tsybulnyk on Friday, September 3, 2010 6:36 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Немного об облаках

Несмотря на шумиху в прессе и в умах, которую пару последних лет производит Майкрософт по поводу своей (и не только своей) "облачной" (cloud) стратегии, очень многие опытные разработчики и руководители всё ещё не совсем представляют как эти изменения отражаются (отразятся) на их непосредственной профессиональной деятельности. Хорошим примером для меня стало то, что когда я сообщал своим коллегам в Майкрософт (а также экс-коллегам, друзьям и просто знакомым соратникам по цеху) о своём переходе в команду разработки Windows Azure, наиболее распространённой реакцией была "А что он делает этот Windows Azure?" Поэтому я и решился на написание этого поста - одним махом дать представление о прогрессе в облачном движении вообще и том вкладе, который в это движение делает Microsoft.   Для меня концепцию "облачного" движения проще всего раскрывать в сравнении с каким-либо другим технологическим скачком человечества, позвольте мне остановиться на примере изобретения и внедрения электричества.   Облака вчера.  Основные идеи cloud computing совершенно не новы. По сути, "облаком" можно назвать любой ресурс или приложение, используемое параллельно несколькими (многими) пользователями. Пожалуй даже самые первые суперкомпьютеры, с которыми большое число пользователей работало по принципу терминального доступа, уже можно относить к первым образцам "облака". Этот этап в создании и освоении "облачной" идеи можно сравнить с периодом 1650-1700 гг, когда Отто фон Герике экспериментировал со своей электрической машиной по извлечению искр из натираемого шара, которые и были по сути первыми экспериментами с электричеством. Однако технологии быстро развивались, и появление в конце 1980-х Интернета можно смело назвать зарождением "облачной" идеи в том виде, в котором мы её знаем сегодня: хост-провайдеры предоставляли платформу, на которой владельцы приложений могли разворачивать свои веб-приложения для использования их в качестве сервисов. Проводя параллели с освоением электричества, это период с 1700 по 1825 годы, когда такими учёными как Вольт, Фарадей и Ом были открыты, сформулированы и использованы все основные законы электростатики и электродинамики. Однако до массового использования этих знаний оставалось ещё пол века. Если бы мы в это время подошли к случайному прохожему и спросили "как вы относитесь к электричеству?", нас мы скорее всего встретил недоумённый взгляд.   Облака сегодня. Что же произошло два или три года назад такого, что послужило толчком всей этой "облачной лихорадке", которую мы наблюдаем сегодня? Попросту говоря, технологии и инфраструктура Интернета достигли уровня, достаточного для того, чтобы всерьёз говорить о предоставлении совершенно любых приложений в виде интернет-сервисов. Интернет стал такой же неотъемлемой частью нашего быта, как водопровод, телефон и то же самое электричество, которое достигло аналогичного этапа в своём развитии в 1870-х годах, когда были сконструированы первые электрогенераторы и начали строиться первые электростанции, а на улицах Парижа вспыхнули первые дуговые электролампы. Windows Azure - это по сути и есть электростанции, которые позволяют потребителям облака не заботится о построении облачной инфраструктуры, достаточно просто купить этот сервис у людей, делающих это профессионально. Покупая доступ к облаку Microsoft, Amazon, Google или любому другому, вы избавляете себя от необходимости крутить динамо-машину и трансформировать полученное электричество, вы просто подключаетесь к линии электропередач и платите за количество потреблённых кВатт-часов. Облака завтра. Собственно будущее облаков вобще и  Windows Azure в частности и натолкнуло меня на написание этого поста. Многих потребителей не устраивает зависимость от централизованой электрической сети - хочется и гарантий независимости, и 100% надёжности. Точно так, многих в облачной идее смущает именно вопрос безопасности конфиденциальных данных размещённых в публичном облаке, а также надёжности предоставляемого сервиса. Для 95% потребителей надёжность и безопасность data-центров того же Microsoft на две головы превосходит надёжность того, что они могут построить сами. Однако оставшиеся 5% (а в будещем это число может расти) хотят и могут платить за то, чтобы иметь надёжное облако и безопасное для себя и только для себя. Именно для этой категории пользователей  Microsoft анонсировал Windows Azure Platform appliance - платформу  Windows Azure, которую клиенты смогут разворачивать на своих собственных data-центрах. Таким образом для пользователей, инвестирующих в разработку своих сервисов под Windows Azure сейчас, гарантируется что они могут быть в будущем перенесены в приватные data-центры на базе Windows Azure Platform appliance:       We are delivering a game-changing cloud service with Windows Azure.  Windows Azure is the world’s first all-purpose cloud platform that allows customers to focus on creating business solutions without worrying about the underlying infrastructure.  At the same time, we are enabling customers to build their own cloud within their custom environments using our Windows Server, SQL Server, and System Center products. Building on these unique assets, at WPC, we took a big step forward with the announcement of the Windows Azure Platform appliance, a turnkey cloud platform that customers can deploy in their own datacenters, spanning from hundreds to thousands of servers. When we announced the launch of the first wave of the Windows Azure appliance, we effectively changed the cloud game in the industry.  Through this announcement, we’re making cloud computing more accessible than ever before by taking everything we've learned through running clouds ourselves (Hotmail, Bing, Microsoft Online Services, etc.), packaging it up, and delivering it to the industry.  With the help of companies like Dell, eBay, Fujitsu, HP and others, we believe this innovative step will change the face of cloud computing. With the announcement of the Windows Azure appliance, Microsoft has redefined cloud computing by being the only vendor that is delivering across all aspects of the cloud. Мне кажется, что это один-в-один повторяет тенденцию использования особо энерго-зависимыми учреждениями (и частными лицами) электрических мини-генераторов или портативных электростанций чтобы обезопасить себя от перебоев с поставками электроенергии и от стратегической зависимости от этих поставок, что в очередной раз подверждает теорию спиральности технического прогресса, когда все новые идеи и открытия всегда отражают некие старые, только уже в новом качестве.

Posted by Vitalii Tsybulnyk on Friday, July 16, 2010 10:33 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Успешная человеческая многозадачность в софтверной разработке

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

Posted by Vitalii Tsybulnyk on Sunday, June 27, 2010 6:29 PM
Permalink | Comments (2) | Post RSSRSS comment feed

Пирамидальная карьера Рико Мариани

Rico Mariani занимает позицию Partner Software Architect в Microsoft и является неиссякаемым источником профессиональной мудрости для множества работающих с ним людей. На одной из недавних презентаций, приуроченных к Microsoft Engineering Forum в этом году, Рико рассказал своё видение успешной карьеры IT профессионала, что волшебным образом совпало с моим представлением, так что я не смог не привести его здесь. Рико образно изображает успешную карьеру в виде геометрической фигуры - пирамиды. Пирамида в данном случае выступает как противоположность башни, когда карьера строится на опыте определённого рода, совершенствуясь лучше и лучше в этой определённой области, то такую модель карьеры можно сравнить с высоким зданием с небольшим основанием. Вам кажется "как быстро я расту, как стремительно движется моя карьера", однако скрытый недостаток такой модели в том, что на определённой высоте "уже никто не захочет ложить кирпичи на такую башню из-за угрозы падения". В то же время уже поздно расширять основание, т.к. "вы уже слишком высоко, вы уже не можете вернуться к основам". "Намного лучше начать с широкого базиса и строить вверх, опираясь на него и постоянно расширяя его ещё больше по мере роста". Широкий базис включает разнородные знания и умения, опыт работы в разных ролях и областях, что даёт очень устойчивое и надёжное основание для роста вашей карьеры вверх, образуя таким образом треугольник. Этот треугольник может быть неидеальным, с несколькими "пиками" в разных местах, однако именно широкое основание даёт представление об устойчивости этой фигуры. "Такая карьера намного труднее, занимает дольше, но это даёт лучший результат в долговременной перспективе". Для меня прелесть такой карьеры в том, что вы никогда не оказываетесь в ситуации, когда вы выросли настолько, насколько могли, и на этом ваша карьера достигла естественного максимума. При такой модели вы всегда можете переместиться "в сторону" вместо "вверх" и продолжить своё "строительство" там. Это перемещение может быть сменой технологий (desktop-> web, server -> client), ролей (manager -> individual contributor) или даже дисциплин. Так мы получили треугольник, но ведь пирамида - это трёхмерная фигура. Что же в данном случае символизирует это третье измерение, что делает пирамиду объёмной? Этим третьем измерением Рико называет вашу индивидуальность, то что вас увлекает, обогащает, интересует в этой жизни. Это может быть семья, игра на музыкальном инструменте, путешествия, выращивание растений - всё что угодно, что приносит вам радость от жизни. Величайшая неординарность и одновременно жизненная мудрость Рико заключается в том, что он вносит этот аспект вашей личности как неотъемлемую и органичную часть успешной карьеры. Мудрость эта, во-первых, заключается в том, что вы не сможете всегда на 100% выкладываться в своей работе, если она лишает вас того, чем вы занимаетесь, чем вы живёте всё остальное время. Карьера никогда не должна убить эту вашу индивидуальность, поглотить всего вас. К сожалению, приходится видеть людей, не учитывающих этого и посвящающих всего себя работе, и это работает год, работает два, пока человек не превращается в раздражённого зомби, не удовлетворённого ни работой, ни всей своей жизнью в целом. Только счастливый, довольный своей жизнью человек может стабильно быть креативным и продуктивным в своей работе, а значит построить долговременную, устойчивую карьеру. Вторая мудрость - даже вне работы, вы всё ещё тот же человек, и тот жизненный опыт, те умения и качества, что вы приобретаете вне работы, те решения, которые вы принимаете, они обогащают всего вас, и вашу "рабочую" часть в том числе, они позволяют воспользоваться опытом и креативом, накопленным в повседневной жизни, в профессиональных целях. Человек, живущий богатой и полноценной жизнью, создаёт более широкий и устойчивый (основание пирамиды) базис для своей профессиональной карьеры.

Categories: Management | Microsoft
Posted by Vitalii Tsybulnyk on Monday, June 14, 2010 9:44 AM
Permalink | Comments (2) | Post RSSRSS comment feed

Planning Good QA Automation Scope

It seems to me that the most important part of a successful automated test infrastructure is an elegant approach for test planning/coverage/prioritizing. Below are my thoughts and ideas on how this approach should look for a high-quality long-term software project. In order for your automated tests to be reliable and fast enough, but also to test the product the same way customers actually use it, you should have different types of tests for different purposes. Here is a classification which looks reasonable to me: · Feature (API) tests – each test in this category should cover one particular small product feature. You should exclude all extra product activity (e.g. pre-requisites creation, product configuration) and replace it with test code. This test should run in the fastest and the most reliable way, so API should be used instead of UI when possible. Feature tests have to be 100% reliable and fast, so you should be able to run them nightly. · Scenario (UI) tests should cover several (not many) features each and test them the way the customer really uses them – via UI. To keep these tests comparatively short, some pre-requisites might be pre-created with test code; however all steps involved into customer scenario should be done with UI. Each scenario test will probably cover several features, so Coverage matrix should be tracked to make sure that the feature coverage is full and even, e.g.:   Scenario 1 Scenario 2 Scenario 3 Scenario 4 Feature 1 X X Feature 2 X X X Feature 3 X X Feature 4 X X X Feature 5 X X X Scenario tests take much longer to execute and are less reliable then feature tests (because they use UI, a problem in one feature could fail several scenarios, etc.), so they should be run rarely. · End-to-End (UI) tests cover many features (often the whole feature area), which makes this test the closest representation of actual user activity and provides the highest level of integration testing. E2E tests are super long and the least reliable among all test types, so they should be run very rarely. · Stress (API) tests are in fact feature tests, but run many times each. Test infrastructure should allow for running feature tests just in ‘stress’ mode, without writing separate stress tests. · Fuzz (API) tests are in fact feature tests, but run several times each with different prerequisites and various (random) input. Test infrastructure should allow for running feature tests just in ‘fuzz’ mode without writing separate fuzz tests. So you should plan and run tests according to the matrix of test types and test targets, e.g.:   Feature (API) Scenario (UI) E2E (UI) Stress (API) Fuzz (API) Module 1 nightly weekly monthly monthly monthly Module 2 nightly weekly bimonthly bimonthly bimonthly Module 3 weekly monthly bimonthly bimonthly bimonthly or   Feature (API) Scenario (UI) E2E (UI) Stress (API) Fuzz (API) OS 1 nightly weekly monthly monthly monthly OS 2 nightly weekly bimonthly bimonthly bimonthly OS3 weekly monthly bimonthly bimonthly bimonthly

Categories: Development | Management
Posted by Vitalii Tsybulnyk on Friday, June 11, 2010 7:23 AM
Permalink | Comments (2) | Post RSSRSS comment feed

The Surprising Truth About What Motivates Us

The Royal Society for the Encouragement of Arts, Manufactures and Commerce (RSA) recently published a very impressive video of Dan Pink presenting the surprising truth about what motivates us. This video is definitely worth spending 40 minutes of your life watching it, but there is also a very nice smaller 10-min animated version of it for those who'd prefer to know a short summary instead of a whole story. Dan's talk is built around the problem of motivation. The first surprising 'truth' he discovers is that money is not, in fact, a real motivator in the present world. Money is only a good motivator for simple, straightforward jobs. For creative, complex jobs an absence of money is a demotivator, however once you pay enough, it stops being a motivator at all. What are the real motivators then? They are: AUTONOMY - our desire to be self-directed. The traditional goal of management, 'to control', was invented in 1850's and simply doesn't work in a today's world of complex creative jobs. MASTERY - our desire to make progress, to get better at what we do. This is one of the most significant components of our satisfaction from work. PURPOSE - we want to be a part of something bigger, something that makes world better. Dan provides many very impressive examples and research results, so I'd recommend watching the original video to get your own impression.

Posted by Vitalii Tsybulnyk on Wednesday, June 9, 2010 10:08 AM
Permalink | Comments (2) | Post RSSRSS comment feed

Quotes about Teams and Methodologies

Stephen F. Heffner left some wonderfull comments at Software Engineering Productivity discussion on LinketIn, I'd like to quote some of them: Many "methodologies" are all about getting satisfactory results from unsatisfactory programmers. A team of really good programmers is likely to have its own "methodology" based on the team's experience and talent. In that case, methodology doesn't detract from the fun -- it just organizes it and keeps it streamlined. Being "part of a much bigger team" is a recipe for disaster. Any programming team bigger than 3-5 is too big already. If the programming manager thinks it takes a bigger team, he/she needs to hire fewer but better programmers, and also needs to read about Brooks' Law.

Categories: Management
Posted by Vitalii Tsybulnyk on Wednesday, May 26, 2010 5:12 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Офисная байка про муравья

Не встретил никакой информации о правах на текст, так что привожу его здесь без правок и изменений.   Офисная байка про муравья Каждый день, с утра по раньше приходил на работу продуктивный и весёлый МУРАВЕЙ. Была у него хорошая производительность и весёлым он был. И деятельность фирмы была успешной но... ШМЕЛЬ, генеральный директор фирмы где работал МУРАВЕЙ, решил, что МУРАВЕЙ не может работать сам по себе, так что была создана должность надсмотрщика и нанял он НАВОЗНОГО ЖУКА. Самой главной заботой ЖУКА - НАВОЗНОГО была организовать работу МУРАВЬЯ. И заставил он МУРАВЬЯ делать отчёты о ежедневной проделанной работе. Вскоре понадобилась должность секретаря, который бы помог жуку в чтении и регистрации отчётов МУРАВЬЯ. Поэтому наняли ПАУЧИХУ, которая классифицировала документы и отвечала на телефонные звонки. Между тем, счастливый МУРВЕЙ работал, работал, работал... ШМЕЛЬ, был очень доволен отчётами НАВОЗНОГО ЖУКА, так что запросил дополнительные отчёты, прогнозы и расчёт различных показателей. В таком случае, необходимо было нанять ТАРАКАНА в качестве ассистента НАВОЗНОГО ЖУКА. ... а также купить компьютер и цветной принтер. Вскоре, производительный и счастливый МУРАВЕЙ, начал жаловаться на все разборки и отчёты который должен был предоставлять, и всё менее веселей ему становилось. ШМЕЛЬ, генеральный директор, понимает, что необходимо принимать меры. Так что, на месте где работал продуктивный и ещё весёлый МУРАВЕЙ бал создан департамент. На должность начальника был назначен КУЗНЕЧИК. Он соорудил себе современный кабинет и оборудовал соответственно. Новому начальнику департамента понадобился ассистент, который помог бы ему в подготовке стратегических планов и бюджета департамента в котором работал продуктивный и весёлый МУРАВЕЙ. Но МУРАВЕЙ уже не пел как раньше и становился всё более раздражительным... Однажды, генеральный директор, посмотрев на цифры, понял, что департамент где работает МУРАВЕЙ, не является уже таким же рентабельным как раньше. Подумав, ШМЕЛЬ решил нанять в качестве консультанта СОВУ, для проведения диагностики. СОВА просидела 3 месяца на фирме, и, после изучения дела, сделала заключение: "В департаменте слишком много персонала.." ...следуя совету специалиста, провели сокращение численности. МУРАВЕЙ оказался первым в списке, т.к. всё время был недоволен... Мораль: Даже и не думай быть счастливым и продуктивным муравьём. Лучше быть некомпетентным и бесполезным. Некомпетентным не нужны надсмотрщики,... все и так понимают почему. И, если, несмотря на твои "усилия", ты всё же продолжаешь оставаться продуктивным, не показывай ни за что на свете что ты счастлив и весел. Тебе этого никогда не простят. Но если вопреки сказанному выше, ты упрямо продолжаешь оставаться СЧАСТЛИВЫМ И ПРОДУКТИВНЫМ МУРАВЬЁМ, работай на себя, так чтобы не нести на своей спине шмелей, навозных жуков, тараканов, пауков, кузнечиков и сов.   И хотя я не совсем согласен с выводами в разделе "Мораль", многие события из байки честенько имеют место в реальной жизни...

Posted by Vitalii Tsybulnyk on Wednesday, May 19, 2010 5:03 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Антипаттерны перехода на гибкие методологии

В последнее время мне всё чаще и чаще приходится выслушивать негативные впечатления от моих друзей, знакомых и экс-коллег, связанные с переходом ИТ-компаний на гибкие (agile) метологии. В частности, наибольшую популярность (и как следствие, народное недовольство) снискал переход на Scrum. С грустью наблюдая, как порочиться доброе имя Scrum-методологии, и вдохновлённый идеями lean production, я решился написать эту заметку чтобы перечислить основные ошибки, допускаемые компаниями и командами при переходе на agile, в частности Scrum. Некоторые из этих ошибок я уже приводил в своих предыдущих статьях или комментариях к ним, но собрать и обсудить их в одном месте мне всё-таки показалось ценным и актуальным. Итак, основные антипаттерны перехода на гибкие метологии: 1. Непонимание роли руководства при внедрении методологии. Переход на многие гибкие методологии (Scrum, XP) подразумевает координальную смену задач и методов работы руководителей. В двух словах этот переход можно сформулировать как переход от управления к направлению, переход от приказов и указаний к рекоммендациям. Первая ошибка, которая допускается при таком переходе - подсознательное стремление сохранить за собой власть, ведущее ко всё тому же управлению, но замаскированному идеями agile. Вторая, не менее серьёзная ошибка прямо противоположна - неправильное понимание этого перехода может привести к устранению менеджеров от руководящих функций, когда руководитель перестаёт давать указания, но так и не начинает давать рекомендации. Роль руководителя при этом сводится к чисто формальным, секретарским функциям. Причиной этого может быть и неготовность руководителей давать аргументацию своему мнению (в старой модели им этого зачастую делать не приходилось) или боязнь невыполнения высказанных рекоммендаций. 2. Построение «системы», не обладающей необходимой гибкостью. Отсутствие опыта работы по новой методологии ведёт к тому, что новый процесс внедряется по инструкциям, буква к букве, что ведёт к негибкости и бюрократизации. 3. Начало внедрения не с «основ». При переходе на новые методологии руководство преследует конкретные выгоды, которые должна обеспечить методология: высокая производительность, качество и т.п. При этом некоторые практики нового процесса более очевидно ведут к этим выгодам, а некоторые - совсем не очевидно. В связи с этим возникает соблазн внедрить сначала более "выгодные" практики, а потом уже остальные. При этом не учитывается, что некоторые практики являются базовыми по отношению к другим, и внедрение вторых без первых невозможно. Пример: внедрение таких практик XP как рефакторинг или коллективное владение кодом без отработанной практики юнит-тестирования гарантированно приведёт к резкому ухудшению качества. 4. Изменяются рабочие места, но не меняются привычки. Провозглашение новых правил и следование этим правилам - это, как говорят в Одессе "две большие разницы". Недостаточное понимание новых идей всеми членами команды или слабое осознание выгод от перехода на новый процесс, слабая мотивация, отсутствие переходного периода с явно выраженными послаблениями в графике работ и количестве задач - это далеко не полный список ошибок, способных привести к тому, что новый процесс может соблюдаться лишь формально "для видимости", а в действительности саботироваться членами команды. 5. Все измерять (собирать данные), но ни на что не реагировать. Бесконечный анализ ситуации, вместо непрерывных улучшений («Паралитический анализ»). Большинство гибких методологий подразумевают сбор метрик и обязательную рефлексию - обсуждение ощибок, совершённых на предыдущем этапе, перед началом следующего. Распространённые ошибки в этой сфере - сбор метрик без их последующего анализа или неверная, слишком поверхностная интерпретация метрик; рефлексия без внесения изменений в процесс (или внесение симптотических, экстенсивных изменений). 6. Обходиться без поддержки. Отсутствие опыта работы команды по новой методологии и внедрение по букве инструкций таит много ошибок, неверных интерпретаций и недопонимания. Только участие в процессе перехода опытного инструктора, имеющего непосредственных опыт работы по новому процессу, может избавить команду от множества неверных поворотов и тупиков, или в отдельных случаях даже от построения совершенно неверной методологии.

Categories: Agile | Management
Posted by Vitalii Tsybulnyk on Monday, April 26, 2010 9:31 AM
Permalink | Comments (6) | Post RSSRSS comment feed

Dogfooding: Собачий корм и с чем его едят

Dogfooding (поедание собачьего корма) - это использование внутри компании своих собственных продуктов. Практикуется во многих крупных софтверных компаниях: Microsoft, Google. Преимущества: * Возможность получить более подробные отзывы пользователей в более короткие сроки * Большая уверенность в достаточном качестве продукта * Более точное разделение приоритетов исправлений и доработок * Стимулирование быстрого исправления критических ошибок Недостатки: * Требует наличия пригодной к использованию версии продукта * Проблемы в одном продукте могут стать существенной головной болью для всего бизнеса * Использование продукта узкой группой людей может дать неверные оценки и отзывы по сравнению с равномерной выборкой Взвесив все вышеперечисленные "за" и "против" и вооружившись опытом, можно однозначно утверждать, что dogfooding должен иметь место при производстве софтверных продуктов. Однако необходимы максимальные осторожность и здравый смысл при выборе момента начала dogfooding'а, т.к. неправильно выбранная версия продукта или стадия цикла разработки могут многократно уменьшить его выгоды и усугубить недостатки.

Categories: Management
Posted by Vitalii Tsybulnyk on Monday, April 12, 2010 4:41 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Рейнджеры и солдаты: о подчинении в софтверной индустрии

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

Posted by Vitalii Tsybulnyk on Friday, April 2, 2010 11:59 AM
Permalink | Comments (3) | Post RSSRSS comment feed

Ситуативное лидерство как шаг на пути к эффективному руководству командами

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

Categories: Management
Posted by Vitalii Tsybulnyk on Friday, March 19, 2010 4:03 AM
Permalink | Comments (3) | Post RSSRSS comment feed

Знания, Отношение, Способности и Привычки

Сегодня я поделюсь подходом под названием KASH box model: Knowledge / Знание – что вы знаете. Attitude / Отношение – ваше отношение со всеми лежащими в основе ценностями и выгодами. Skills / Способности – ваши возможности. Habits / Привычки – что вы на самом деле делаете. Этот подход позволяет значительно упростить понимание разрыва между знанием и деланием и всех связанных с этим проблем:  - Как часто вам приходилось видеть, как люди знают, что надо делать, но они этого не делают? Это говорит о том, что мало научить, нужно ещё и приучить.  - В большинстве случаев людей нанимают за знания и способности, а увольняют за отношение и привычки. Другими словами, многие фокусируются на знаниях и умениях, тогда как реальным тормозом развития являются отношение и привычки. Источники 1. J.D. Meier 'Career Growth and Finding Your Way Forward'

Categories: Development | Management
Posted by Vitalii Tsybulnyk on Wednesday, January 27, 2010 6:18 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Маленькая компания vs. большая компания

В этой заметке я хочу привести и сравнить основные факторы работы в маленьких и больших софтверных компаниях. При этом критерий оценки размеров компании - вопрос весьма спорный, т.к. если, например, компания разделена на небольшине финансово- и управленчески- независимые команды со своими процессами, подходами, инструментарием и т.п., то относить такую компанию в группу больших было бы не совсем корректно. Однако такое устройство больших компаний встречается не так уж и часто, и каждый такой случай достоен индивидуального рассмотрения, так что для простоты будем иметь ввиду большие компании с единым формальным процессом работы над проектами, единым стилем управления и оценки персонала, одним и тем же набором должностей и ролей в командах и т.п. Привести какие-то оценочные цифры количества сотрудников также довольно проблематично, поэтому речь скорее пойдёт не о сравнении компании с таким-то числом сотрудников, а о тенденциях, имеющих место при сравнении компаний большего или меньшего размера. Эти тенденции более или менее однинаковы для разных масштабов сравнения, например, при сравнении работы фрилансера с работой компании из 50-ти человек, и работы компании из 50-ти человек с работой компании с 2000-ным штатом. Цель заметки - привести и сравнить как можно больше критериев, влияющих на выбор компании, а не дать итоговое сравнение "кто победил", т.к. важность определённых факторов для разных людей совершенно различна. Кроме того, даже само положительное или отрицательное значение каждого фактора весьма субъективно: например, я оценил тесные коммуникации и отсутствие формальностей как преимущество, однако я знаю примеры людей, воспринимающих это как недостаток. Фактор сравнения<- меньше компаниябольше компания -> Размер проектов (объём требований, сроки):   ? опыт прохождения полного цикла работы над проектом   ? техническая и управленческая сложность и значимость проектов   ? число разных освоенных технологий и подходов, кругозор   ? глубина овладевания и использования технологий и подходов  меньше:   + больше проектов   - ниже   + больше   - меньше  больше:   - меньше проектов   + выше   - меньше   + больше Количество людей в командах:   ? круг обязанностей каждого участника (кругозор)   ? охват ролей в проекте (возможность практиковать новую роль)   ? совершенство овладенвания своими обязанностями/ролью   ? индивидуальный вклад каждого участника   ? давление на каждого участника   ? зависимость общих результатов от каждого участника   ? оценка/самооценка сотрудников   ? вероятность быть подавленным более сильными коллегами   ? возможности менторства/помощи от более опытных коллег  меньше:   + шире   + шире   - ниже   + выше   - больше   - больше   + объективнее   + меньше   - меньше  больше:   - уже   - уже   + выше   - ниже   + меньше   + меньше   - формальнее   - выше   + больше Тяжеловесность/легковесность процессов:   ? наличие формализма и бюрократии   ? коммуникации   ? возможность оказывать влияние на процесс   ? возможность освоить проверенный эффективный процесс легковеснее:   + меньше   + теснее   + больше   - меньше тяжеловеснее:   - больше   - формальнее   - меньше   + больше  

Categories: Development | Management
Posted by Vitalii Tsybulnyk on Tuesday, December 29, 2009 5:47 AM
Permalink | Comments (7) | Post RSSRSS comment feed