Привет! Меня зовут Алексей Архипов. 20 лет в IT. Я – менеджер проектов с широким техническим кругозором. Последние годы специализируюсь на электронной коммерции, и могу в одиночку запустить средний проект с нуля и до обеспечения его эксплуатации.
Хотите больше подробностей? Вот резюме на сайте и на HeadHunter, или на Хабр.Карьера.
А еще можно посмотреть портфолио моих проектов.
И швец, и жнец, и на дуде игрец
Работаю
Выступаю
Консультирую
Изучаю
Многостаночник
За свою карьеру мне пришлось примерить на себя множество ролей. Я прошёл все этапы от программиста до управления проектами. Был тестировщиком, поддерживал пользователей, проводил аналитику требований и сейчас являюсь специалистом очень широкого профиля. У меня получается ладить с людьми, могу обеспечить найм необходимой команды. Специализируюсь на антикризисном управлении: всю карьеру имел дело с проектами с большим накопленных количеством проблем.
И чем только не приходилось заниматься… Я участвовал в проектах для больших и малых коммерческих организаций, для государства и даже для оборонной промышленности. Нанимал и увольнял, был стартапером и корпоративщиком, разработчиком и тестировщиком, архитектором, менеджером проектов, владельцем продукта со стороны заказчика и всё что между. Этот опыт дал мне понимание всех этапов проектного менеджмента. Я всегда был нацелен на результат, а не на процесс, и мне нравится работать с командами и людьми того же склада. Теми, кто хочет быть лучшим в своем деле, а не просто достаточным для своего места.
Мой подход к проектному менеджменту напоминает трехногий стул: первая ножка это легковесный и гибкий рабочий процесс, вторая – детальное предварительное планирование и третья – лидерство на личном примере. Я работал по гибким (agile) и классическим (waterfall) методологиям, и понял что каждый проект должен быть настроен индивидуально, чтобы быть выполненным в срок, бюджет и согласно поставленным целям. Я верю что успех проекта кроется в выстраивании доверительных отношений с Заказчиком и встраивании его в повседневный рабочий процесс, чтобы получить максимальное ускорение процесса. Первоначально обученный управлению проектами по PMI PMBOK, позднее я начал брать лучшее из разных методик, создавая в итоге успешные проектные команды.
Помимо навыков управления, моей особенностью как специалиста является широкий круг технических знаний. Мне приходилось иметь дело с операционными системами Windows, Linux and MacOS (в том числе программирование в командной строке), базами данных (MS SQLServer, MySQL, PostgreSQL, Oracle), Java (SE, ME, JavaCard), технологиями С# и Web (XML, HTML, JavaScript, PHP, Perl, Python), VBA и даже больше. Конечно можно сказать “чем лужа шире тем она мельче”, невозможно быть профессионалом во всем, тем не менее широкий кругозор часто выручал меня в кризисных ситуациях, особенно в многокомпонентных проектах, проблемы в которых часто возникают на стыках различных технологий. Как следствие, я постоянно учусь, в случае необходимости быстро погружаюсь в новую предметную область, и могу заменить почти любого члена команды, исключая, пожалуй, дизайнера.
Долгое время я фрустрировал о ненужности широких специалистов на локальном рынке, пока на примере методички от Valve не убедился в совершенно обратном. Подобные мне специалисты широкого профиля наиболее полезны:
- Стартапам – в проекты, где конечные требования еще не определены или часто кардинально меняются, от чего потребность в узких специалистах временно сложно определить.
- Кризисным проектам – при недостатке специалистов, с большим количеством накопленных проблем, неудачной архитектурой и низким качеством кода.
{photo T-shape}
Источник: Valve: Handbook for new Employees
В теории работа с проектами описывается тройственными ограничениями:
На практике, по моему опыту, на проект влияет гораздо больше факторов:
Коммуникации
“Порой перед программистом встает непреодолимая задача – позвонить по телефону”. Умение организовать совместное обсуждение, переговорить по телефону или встать и сходить спросить как дела у разработчика всегда помогает предупреждать возникновение проблем, вызванных плохими коммуникациями.
Работа – это про людей, а не про ресурсы. И для успешного завершения проекта требуются не только сильные технические навыки, а порой простое умение внимательно объяснить проблему, организовать общекомандный митинг или просто поговорить по душам.
Обеспечение качества и тестирование
Не все мои проекты были успешными. Время научило меня быть толерантным к странным запросам клиентов и поддержке унаследованного кода. Тем не менее мне приходилось участвовать в вытягивании проектов из кризиса, с чем в большинстве случаев успешно справлялся. Я совершал много ошибок, но теперь знаю как их избегать.
Анализируя причины своих ошибок, я пришел к выводу, что наиболее частой их причиной являются нечетко поставленные требования и/или плохое тестирование. С тех пор я ценю тестировщиков не ниже программистов.
Последние годы я занимаюсь консалтингом IT-компаний в области обеспечения качества, и выпустил в Томском Университете Систем Управления и Радиоэлектроники (ТУСУР) 3 группы повышения квалификации по теме “Обеспечение качества в IT-проектах”, обучив порядка 50 человек.
{фото}
Чаще всего приходится организовывать процесс тестирования чужими руками. Однако иногда приходится засучивать рукава, и лезть во внутренности системы самостоятельно, в поисках дурно пахнущего кода или критических ошибок архитектуры. Очень важно вовремя привлекать заказчика к тестированию готовых фич, это позволяет работать по принципу “Fail Fast” и устранять проблемы заранее, но также тут требуется искусство останавливать заказчика от уходов в сторону неготовых компонентов и заваливания команды новыми хотелками.
Оценки сроков и стоимости
“Вот салфетка с задачей, оцени сколько времени и денег тебе нужно”. Оценка – это проблема курицы и яйца. Пока нет внятного описания задачи – вы не можете дать четкой оценки стоимости без понимания полного объема работ, клиент же, как обычно, отказывается начинать работу до четкой договоренности о цене. Хорошим конпромиссом в таких случаях являются несколько вариантов стоимости при различных предположениях о стоимости неопределенных компонентов. По крайней мере это хороший повод для продолжения разговора и уточнения неизвестных. Такие уточненные предложения в дальнейшем могут стать основой описания скоупа проекта, который клиент должен будет подписать для старта проекта.
Инструменты
Cреди моих повседневных инструментов: Asana, Trello, Dropbox, Evernote, Word, Excel, Git, Gmail, Google docs, Jira, RedMine, Photoshop, Skype, Slack и WordPress.
Технические компетенции
- OS: Windows, Linux, MacOS
- VCS: Git, Subversion
- RDBMS: Oracle(+PL/SQL), PostgreSQL(PostGIS, TimescaleDB, Pg/SQL), MySQL(MariaDB), MS SQL Server (+ T/SQL)
- NoSQL: MongoDB
- CI\CD: Jenkins(Hudson), TeamCity, GitLab CI
- Frontend Frameworks & Specs: Webix, React+Redux, Angular+NgRx, HTML, CSS, XML, npm
- Containerization: Docker, Swarm
- Orchestration: Ansible
- Backend: PHP, Java SE, .Net Core, Python, Node.js
- Bash-scripting
- Redis, Memcached
- Устаревшие технологии: perl, awk, sed, VBA
Дополнительные сведения
Agile, Kanban, DevOps, CI/CD, бирюзовые организации, Toyota DAO, теория ограничений и другие модные течения – в курсе.
Языки
- Русский – родной
- Английский – С1, Intermediate
- Немецкий – A1, Beginner
- Испанский – начну учить после достижения среднего уровня в немецком 🙂
Хотите знать больше? Тогда спросите. Я всегда открыт для новых возможностей и буду рад выслушать Ваши предложения.