14 записей с тегом "управление"

Listened to the podcast https://www.tpg.ee/p/product-team-models-project-based

Was interesting to listen and reflect how organizations tend to have indeed different structures. I suppose the project-based is a tendency in small and outsourcing companies, while more mature product-orinented companies go with feature-factories. I don't think I've seen a good implementation of the described product operating model myself. It seems hard to do such a company-wise mindset shift because people are narrow-focused on their role and thinking outside the box requires jumping through multiple layers. Even if companies are matrix-shaped and have vertical teams, they are not representing all layers. For example sales, marketing, support and infrastructure likely won't be part of the the team.

So I do wonder how does Aive Uus break those mindsets 😄 Hopefully we'll see more of this

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

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

Я мало что понимаю в менеджменте, поэтому меня больше интересуют вопросы конфликтов и улучшение инспекции кода для улучшения продукта и сплочения команды.

четверг, 19 марта 2015 г. в 02:57:12

Набрёл на интересную бесплатную книжку Тамары Кулинкович по психологии (см. пост на хабре). Сама она занимается HR-процессами, визуализацией данных и тп. Суть в потребностях людей. Будете их удовлетворять - у вас будет хороший продукт

суббота, 21 февраля 2015 г. в 21:02:54

Кайдзен — по-японски означает «изменение к лучшему», это нечто типа трезвения и осознанности, полезная практика постоянного самосовершенствования (constant improvement) ради всеобщего блага. Популяризируется она благодаря тому что это фундамент, используемый на фабриках корпорации Toyota для эффективного производства.

Первый шаг это устранение потерь. Для этого надо беречь исходные материалы, время, место и работников — словно вы работаете в (после)военное время. Применимо к IT, практика так и называется — бережливая разработка, Lean (англ. скудный). Философски, это избавление от вредных зависимостей.

Посмотрел несколько интересных лекций по эволюции и начал читать книгу "Сумма технологий" С. Лема. 

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

Когда-то в далёком 2008 году я писал про местные IT компании.

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

Продолжаем изучать среду разработки PHPStorm. На этот раз поговорим о задачах. В общем идея в том, что при разработке проекта управляющие в вашейкомпании где-то создают список того что надо сделать или исправить — это всякие инструменты типа Jira, Mantis, Redmine.. Каждая со своими особенностями в том какзадачи описываются и дальше текут в компании.

PivotalTracker — один из таких инструментов, созданный специально для любителей scrum, соответсвенно он оперирует кучками задач (backlog, icebox и тд.). Но суть не в этом..

Основная идея интеграции IDE и task-tracking инструмента в том что-бы

1. Не приходилось постоянно ходить в последнюю для просмотра описания и изменения статуса
2. Открытые табы (файлы) зависели бы от контекста, т.е. от решаемой в данный момент задачи
3. Сохранять список изменённых файлов в рамках задачи (на случай поиска дальнейшего дебага)

Scrum - одна из методик гибкой разработки программного обеспечения для небольших комманд.

Суть — цикличность и самокоррекция на основе обратной связи (с клиентом, процессом и тп.)

• Регулярные ежедневные встречи всей комманды синхронизируют её.
• Разработка происходит циклами по 1-4 недели (спринт) и как правило завершается выпуском части продукта.
• В начале спринта происходит планирование задач (1-2ч)
• В середине спринта может происходить подготовка задач к следующему спринту (груминг)
• В конце спринта происходит ретроспектива (sprint review) где обсуждается что прошло хорошо, что прошло плохо, как этого избежать в будующем

Документирование - финальный этап процесса разработки. Если хочется общей картины, то вот как это выглядит в типичном случае:

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

Многие наверняка слышали про Rational Unified Process. Вообще методик по управлению "ресурсами" человеко-часов уйма и принятие одной из них в свою фирму может дать не только бумажку, но и неэффективность всвязи с тем что такая методика не подходит для области деятельности фирмы.

OpenUP - бесплатная методика ( тогда как некоторые более 700$ стоят) и ориентирована на развитие небольших проектов в небольших фирмах (до 36 человеко-месяцев). Вполне подходит для IT, поскольку текучка кадров большая, а проекты стоять не хотят.

Ради достижения успешности проекта, группа разделяется на 3-6 ролей (вспоминаем сразу классы в RPG?):

• клиент
• управляющий проектом
• аналитик
• архитектор
• тестер
• разработчик

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

Несомненно в мире множество фирм в каждой из которых принят некий обычай как проект надо делать, а для этого созданы всевозможные процессы развития проекта типа waterfall, spiral, RUP и тд.

Попробую изложить, как на моём опыте обычно ведётся IT-проект (CMS, CRM, intranet, custom-инфосистема) или как бы этого хотелось в идеале.

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

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