Пожалуй главное наблюдение недели, это не полное понимание принципов конвейера Тойоты и agile многими.
Часто все гибкие методологии заканчиваются на управлении самим продуктом. То что смысл коротких спринтов во многом и в аналогичном управлении командой, далеко не все понимают.
Судя по всему это идёт от непонимания гибких методологий приличной частью управленцев. Для них гибкость нужна только в части конечного результата. Но у них нет понимания, что без права у разработчика влиять на сам процесс производства, идея конвейера Тойоты не работает. Процесс не подстраиваться под продукт и становится всё менее эффективным.
В результате программисты даже на ретре и на один на один привыкают говорить только о продукте. О проблемах процесса производства молчат, так как управленцы не показывают свой интерес к этой информации. В результате такие сотрудники всё дальше уходят от активных участников к состоянию наёмников.
Но правда в том, что те кто делают задачи видят все проблемы проекта и процесса производства. Руководство видит только вершину айсберга. Поэтому критически важно показать всем сотрудникам, что они могут влиять и на управление проектом и на процессы.
Возможно многим управленцам это сложно, так как они боятся потерять свой статус. Но статус нужен на конвейере Форд. На конвейере Тойоты важна работа каждого на результат и тут статус во многом вреден. Статус становится барьером в коммуникации и ухудшает управление.
Кто-то скажет, что это приведёт к хаосу. Но это не так. Сотрудники как раз не хотят хаоса. Большую часть хаоса в гибкой разработке генерируют как раз управленцы, так как вынуждены делать подстройку проекта под рынок. По моему опыту, предложения разработчиков как раз целятся в уменьшение хаоса и ускорение.
Поэтому призываю всех помнить, что гибкие методологии они не только про то, чтобы каждую итерацию делать продукт лучше, они и про то, что каждую итерацию делать управление и сам процесс разработки лучше.
Часто все гибкие методологии заканчиваются на управлении самим продуктом. То что смысл коротких спринтов во многом и в аналогичном управлении командой, далеко не все понимают.
Судя по всему это идёт от непонимания гибких методологий приличной частью управленцев. Для них гибкость нужна только в части конечного результата. Но у них нет понимания, что без права у разработчика влиять на сам процесс производства, идея конвейера Тойоты не работает. Процесс не подстраиваться под продукт и становится всё менее эффективным.
В результате программисты даже на ретре и на один на один привыкают говорить только о продукте. О проблемах процесса производства молчат, так как управленцы не показывают свой интерес к этой информации. В результате такие сотрудники всё дальше уходят от активных участников к состоянию наёмников.
Но правда в том, что те кто делают задачи видят все проблемы проекта и процесса производства. Руководство видит только вершину айсберга. Поэтому критически важно показать всем сотрудникам, что они могут влиять и на управление проектом и на процессы.
Возможно многим управленцам это сложно, так как они боятся потерять свой статус. Но статус нужен на конвейере Форд. На конвейере Тойоты важна работа каждого на результат и тут статус во многом вреден. Статус становится барьером в коммуникации и ухудшает управление.
Кто-то скажет, что это приведёт к хаосу. Но это не так. Сотрудники как раз не хотят хаоса. Большую часть хаоса в гибкой разработке генерируют как раз управленцы, так как вынуждены делать подстройку проекта под рынок. По моему опыту, предложения разработчиков как раз целятся в уменьшение хаоса и ускорение.
Поэтому призываю всех помнить, что гибкие методологии они не только про то, чтобы каждую итерацию делать продукт лучше, они и про то, что каждую итерацию делать управление и сам процесс разработки лучше.
Perhaps the main observation of the week is not a complete understanding of the principles of the Toyota conveyor and agile by many.
Often all agile methodologies end in managing the product itself. The fact that the meaning of short sprints is largely and in the same management of the team, not everyone understands.
Apparently this comes from a lack of understanding of flexible methodologies by a decent portion of managers. For them, flexibility is needed only in terms of the final result. But they don’t have an understanding that without the right of the developer to influence the production process itself, the idea of the Toyota conveyor does not work. The process does not adapt to the product and is becoming less effective.
As a result, programmers get used to talking only about a product even on a retreat and on a one-on-one basis. They are silent about the problems of the production process, since managers do not show their interest in this information. As a result, such employees are moving farther away from active participants to the state of mercenaries.
But the truth is that those who do the tasks see all the problems of the project and the production process. Management sees only the tip of the iceberg. Therefore, it is critically important to show all employees that they can influence both project management and processes.
Perhaps this is difficult for many managers, as they are afraid of losing their status. But the status is needed on the Ford assembly line. On the conveyor of Toyota, everyone's work on the result is important and here the status is largely harmful. Status becomes a barrier to communication and impairs management.
Someone will say that this will lead to chaos. But this is not so. Employees just do not want chaos. Most of the chaos in agile development is generated precisely by managers, since they are forced to adjust the project to the market. In my experience, developers' proposals are aimed at reducing chaos and acceleration.
Therefore, I urge everyone to remember that flexible methodologies are not only about making the product better each iteration, they are also about making the management and the development process better each iteration.
Often all agile methodologies end in managing the product itself. The fact that the meaning of short sprints is largely and in the same management of the team, not everyone understands.
Apparently this comes from a lack of understanding of flexible methodologies by a decent portion of managers. For them, flexibility is needed only in terms of the final result. But they don’t have an understanding that without the right of the developer to influence the production process itself, the idea of the Toyota conveyor does not work. The process does not adapt to the product and is becoming less effective.
As a result, programmers get used to talking only about a product even on a retreat and on a one-on-one basis. They are silent about the problems of the production process, since managers do not show their interest in this information. As a result, such employees are moving farther away from active participants to the state of mercenaries.
But the truth is that those who do the tasks see all the problems of the project and the production process. Management sees only the tip of the iceberg. Therefore, it is critically important to show all employees that they can influence both project management and processes.
Perhaps this is difficult for many managers, as they are afraid of losing their status. But the status is needed on the Ford assembly line. On the conveyor of Toyota, everyone's work on the result is important and here the status is largely harmful. Status becomes a barrier to communication and impairs management.
Someone will say that this will lead to chaos. But this is not so. Employees just do not want chaos. Most of the chaos in agile development is generated precisely by managers, since they are forced to adjust the project to the market. In my experience, developers' proposals are aimed at reducing chaos and acceleration.
Therefore, I urge everyone to remember that flexible methodologies are not only about making the product better each iteration, they are also about making the management and the development process better each iteration.
У записи 5 лайков,
0 репостов,
313 просмотров.
0 репостов,
313 просмотров.
Эту запись оставил(а) на своей стене Alexander Shishenin
