Разбирая завалы файлов на своем старом HDD, Seagate Barracuda 7200.10, объемом аж 80 гигабайт(сейчас туда влезет не всякая игра со стима) наткнулся на интересный документ, который выдавали программистам при приеме в дружную питерскую студию электроников. Он достаточно полно описывал набор знаний, на которые надо было ориентироваться при сдаче ежегодной аттестации. Но помимо соответствия некоторым придуманным требованиям, при поднятии грейда, первую роль конечно играло наличие закрытого объема задач, желание руководства и наличие позиции в штатном расписании.
Были конечно и свои рокстары, которые "спасли контору" или разработали какую-то уникальную технологию в рамках студии, перескочив несколько ступенек сразу, но таких были единицы. В массе же народ просто рос на своих задачах, поднимая грейд каждые 2-4 года. Так что, если кто искал "железные грейды" из кровавого "ентерпрайза" добро пожаловать под кат. Судя по тому, что раздавали этот документ всем желающим, думаю он не был особо секретным или под NDA, на всякий случай убрал оттуда упоминания некоторых продуктов и специфичных технологий. Ну и учтите, что документу скоро будет 10 лет в обед. Требования cгруппированы по областям знаний. Документ так и назывался EA Developer Competency Matrix, переводить на русский не стал, думаю и так все понятно написано. (Оригинал КДПВ тут)
Работая в чисто отечественных, и относительно небольших на тот момент, компаниях возможности познакомиться с этим изобретением зарубежных коллег не было. По рассказам нашего ПМ, такие матрицы способствуют созданию многофункциональных команд. И каждая команда разработки должна обладать всеми навыками, чтобы суметь закрыть таски из бэклога.
Шутка
Врет, чертяка, это точно был способ оставить нас без премии :)
Computer Science (Eng)
SE I (Junior) | SE II(Middle) | SE III (Senior) | PSE (Principal) | |
Data structures | Basic knowledge includes typical containers like Array, LinkedList, and more | Common knowledge about containers involves understanding the differences between Arrays, LinkedLists, Dictionaries, etc., and their practical applications in programming tasks. | Understanding the internal architecture and time trade-offs of data structures such as Arrays, LinkedLists, and Maps is essential. Being able to implement hashtables and properly handle collisions, as well as understanding priority queues and their various uses | Understanding advanced data structures such as B-trees, binomial and Fibonacci heaps, AVL/Red-Black trees, Splay Trees, Skip Lists |
Algorithms | Basic algorithms include the ability to calculate the average of numbers in an array from scratch | Basic sorting, searching and data structure traversal and retrieval algorithms, explain qsort works in paper | Tree, Graphs, greedy algs, divide and conquer handle, able to understand of this matrix math. | Able to explain and code dynamic programming solutions, strong knowledges of graphs, numerical method and algorithms, able to explain NP problems etc. |
Tools | Basic understanding includes knowing what a compiler, linker, or interpreter is. | Basic knowledge includes understanding assembly code and how it operates at the hardware level. Additionally, having some knowledge of virtual memory and paging is beneficial. | Understands the distinction between kernel mode and user mode, multi-threading, synchronization primitives, and their implementation. It's an opportune time to introduce assembly code. Possesses a good understanding of how networks function, basic network protocols, and socket-level programming. | Understands the full programming stack, including hardware components (CPU, Memory, Cache, Interrupts, assembly language), and can write simple assembly code from scratch. Familiar with static and dynamic linking, as well as compile-time issues. |
Software Tools (Eng)
SE I (Junior) | SE II(Middle) | SE III (Senior) | PSE (Principal) | |
source code control | At least one vcs basic stage | VSS and knowleges for CVS/SVN/P4 user | Proficient in CVS and SVN/P4 features, including branch and shelves manipulation, merge operations, applying patches, and managing repository properties effectively. | Understanding of distributed version control systems (VCS), with proficiency in at least one of Bzr, Mercurial, Darcs, or Git. |
automated testing | Writes unittests before the tester | Writes automated unit tests and edge cases hat | Capable of setting up automated functional, load/performance, and common tests. | TDD |
build automation | Build from IDE only | Knows how to build solution from the command line | Can setup a handle scripts to build the basic system | Generate release notes and tag the code in source control |
Programming (Eng)
SE I (Junior) | SE II(Middle) | SE III (Senior) | PSE (Principal) | |
code review | Using monosyllabic names for solution dependencies and employing concise, meaningful names for algorithms, variables, classes, methods, etc. | Avoiding long functions and including comments to explain unusual code, bug fixes, and code assumptions. | Code assumptions are verified using asserts, and code flows naturally without deep nesting of conditionals or methods. | ??? |
Internal tools | Understands internal tools and principles of Continuous Automation/Continuous Integration (CA/CI). | Batch files/ scripts knowledges | Develops Perl, Python, Ruby, JavaScript, and PowerShell applications and scripts for local projects. | Has authored and published reusable scripts in the studio. |
Frameworks | Frequently consults documentation and has experience using frameworks outside of the core platform. | Aware of the most useful and popular frameworks available for the platform. | Has used some frameworks in a professional capacity and is wellcooked with basic idioms from frameworks, authos of project/framework on public resources. | Is an author of framework(s) in public software/solutions. |
IDE | Uses IDE/tools for text editing | Familiar with various Integrated Development Environments (IDEs) and proficient in effectively using IDEs with command-line interfaces (CLI). | Has developed custom macros, internal applications, and delivery tools. | Proficient in custom tool development and adept at analyzing and performing compile-time operations. |
Contract assures | Understanding the concept and principles of error handling. | Asserts critical assumptions in code and utilizes exception handling principles, adhering to no-crash software principles. | Ensures the development of no-crash programs by minimizing state, resource usage, connections, and memory-violating operations. | Maintains a consistent exception handling strategy across all layers of code and devises guidelines for exception handling. |
code organization | Ensures structured organization of data within a file and provides a well-defined structure for organizing code. | Methods are logically grouped or structured, and related structures are organized based on logical dependencies. | Algorithms are organized into spaces and thoroughly commented with references to source groups. Circular dependencies are avoided, and binaries, libraries, documentation, builds, and third-party code are organized into appropriate folders. | The code includes a summary header and is well-commented throughout, ensuring consistency with its usage. The documentation is designed to be aesthetically pleasing. |
decomposition | Utilizes copy-paste coding and leverages resources such as Stack Overflow for handling common tasks and finding solutions. | Capable of breaking down problems into multiple functions. | Able to handle and maintain the codebase for an existing solution that effectively solves the problem. | Invent data structures and algorithms and handle up with generic solutions that encapsulate parts of the problem. |
longlive solution | Capable of thinking beyond the scope of a single file or class. | Capable of breaking down problem areas and providing fluent solutions within the same platform or technology. | Capable of designing systems using multiple technologies and platforms. | Capable of designing complex systems with considerations for multiple product issues, such as monitoring, reporting, failovers, etc., for external systems. |
issue composition | Capable of effectively explaining thoughts and ideas to both individuals and teammates. | Reasonable design of issue components with a strong understanding and expertise in the relevant area and solution. | Capable of effectively communicating the problem stack and possible solutions to the team. | Capable of comprehending and articulating thoughts, designs, ideas, and specifications to the team, stakeholders, and experts, providing appropriate context. |
Experience (Eng)
SE I (Junior) | SE II(Middle) | SE III (Senior) | PSE (Principal) | |
languages | Imperative or Object Oriented language(s) | Imperative, Object-Oriented and declarative concepts, understanding static vs dynamic typing, weak vs strong typing | Functional programming, understand lazy evaluation, currying, continuations | Good knolwdges in concurrent (Erlang) and DOD languages(ADA) and principles |
languages with professional experience | 0-1 | 1-2 | 2-4 | 4+ |
years of professional experience | < 2 | 2-5 | 5-10 | 10+ |
solution knowledge | No projects and shipped solutions | Worked on at least one shipped product | Worked on multiple shipped products in the same domain. | Designed and implemented several products/solutions in the domain, from concept to successful deployment. |
Knowledges (Eng)
SE I (Junior) | SE II(Middle) | SE III (Senior) | PSE (Principal) | ||
tools | Limited to primary IDE (MSVS, Eclipse etc.) | Possesses a strong understanding of editors, debuggers, IDEs, and open-source alternatives, among other related tools and technologies. | Has authored tools and scripts, with an added bonus if they've been published. | ??? | |
blogs | Reads tech, programming, and software engineering blogs irregularly. | Regularly reads blogs and listens to podcasts. Maintains a link blog with a collection of useful articles and tools. | Maintains a blog where personal insights and thoughts on programming are shared. | Author of a popular blog, frequent conference speaker, and maintainer of domain knowledge | |
books | "Code Complete", "Don't Make Me Think", and "Mastering Regular Expressions". | Design Patterns, Peopleware, Programming Pearls, Algorithm Design Manual, Pragmatic Programmer | Structure and Interpretation of Computer Programs, Concepts Techniques, Models of Computer Programming, | "Mythical Man month", | |
consoles | Basic knowledge of platform internals | Good understanding of the internal workings of the platform. | Deep understanding of platform internals and the ability to visualize platform features. | Has developed tools to enhance internals, including disassemblers, decompilers, and debuggers | |
upcoming technologies | Aware of upcoming technologies. | Works with upcoming technologies in the field | Is familiar with alpha preview/CTP/beta releases and has read some articles/manuals on the subject. | Has experimented with previews and has actually built something using them | |
codebase knowledge | Has experimented with previews and has actually built something using them. | Has a solid working knowledge of the codebase, having implemented several bug fixes and perhaps some small features. | Has successfully implemented multiple significant features in the codebase. | Can easily visualize the changes required for most features or bug fixes. |
Еще забавнее получилось, когда американцы внутри команд попросили создать свои матрицы компетенций, чтобы понимать каких людей не хватает. Вот тут мы реально "прифигели" и чуть не переругались с ПМ, потому надо было оценивать как свои, так и чужие навыки, что выглядело банальным "постукиванием"(возможно это и хорошо для американца, но на другой стороне шарика чревато косыми взглядами в курилке). В итоге кое-как отбились от этого документа, свалив обязанности по оценке наших умственных способностей и желанию трудиться на дядю Сёму, обратно на стойкого и умного ПМа, а американцам пространно объясняли про загадочную русскую душу и особенности менталитета.
Уже значительно позже, отработав не один год и с нашими ребятами и с заморскими коллегами пришло понимание, что эта штука не такая уж и плохая. И даже простенькая матрица компетенции помогает лучше планировать спринт и задачи. Как потом оказалось, на основе матрицы можно вытаскивать таски из бэклога, чтобы закрыть пробелы по знаниям у кого-то из коллег или использовать для намеренного увеличения навыков.
Но больше всего полезность проявляется если происходит изменение состава, когда вычеркнув из неё навыки уходящего человека сразу видно какие таски повиснут или отправятся в бэклог, соответственно похожего человека и придется искать на замену.
Перейдя к Gaijin"aм и благополучно забыв всю эту дичь с какими-то матрицами каких-то там компетенций, я с головой ушел в разработку, а сами матрицы стали ассоциироваться исключительно с математикой. Пока не пришлось проводить собеседования и набирать в команду людей. Тут-то и пришла пора задуматься, что каждый проект представляет собой уникальный и неповторимый набор задач и вызовов, не все из которых мы в силах решить, и как раз ключевым фактором успешной разработки является общая компетентность команды.
Что толку от двух рокстаров рендерщиков, если нужно поднять nintendo store и научиться выкладывать туда билды и патчи, или договариваться с японцами о waivers. Можно конечно и рендертим озадачить, только это все равно, что закручивать гвозди микроскопом, закрутить то они закрутят...
Прийдя с этой "новой и молодежной идеей" к ребятам в отделе получил резонный вопрос - "Ты кого-то уволить собрался?". Вполне резонный ответ, ведь уже и сам забыл, как четыре года назад отбрехивался от подобного опроса всеми возможными способами, да только уже на загадочную русскую душу не спишешь, когда все вокруг такие загадочные и такие душ...
Неделю я уламывал коллег, объясняя для чего это все нужно, пообещав, что всё будет использовано только во благо команды.
Потом уже совместно по этой матрице давали оценку кандидатам, пару раз выбирали ребят без особо сильных сторон, но у которых были знания, отсутствующие в команде и это давало свои результаты, потому что начали закрываться давно повисшие или "мертвые" таски из бэклога.
Продолжаю эксперимент уже на новой позиции, постараюсь поделиться результатами в будущем. Интересно есть ли такие матрицы в ваших фирмах, если не под NDA конечно?
Как читать матрицу
Материал представлен "as is", но учтите что ему как минимум 10 лет, а то и больше, это мне он попался на глаза в 2014, а написан и того раньше. И второе он достаточно специфичен для компании, которая а) большая, б) игровая и с) были убраны упоминания отдельных технологий и внутренних фреймворков компании.
Между грейдами была еще ступенька с приставкой A, но там очень мало отличий с базовой. Между SE I и SE II, был еще SE Ia, который получался автоматом за два полных года работы в студии, если просто сидеть на стуле ровно и делать только то, что дает PM.
