Думают ли программисты о бизнесе?
Недавно tgrigorenko написала в FB про "не думающих" ИТ-шниках, которые действуют по принципу "мне сказали - я сделал".
Давайте порасуждаем, откуда возникает такая особенность поведения. Имея опыт работы и с ИТ-шниками и с людьми бизнеса, вижу несколько причин:
1. Оценка качества работа программиста на основе параметра SLOC - количества строк кода, которые были внесены в проект. Для максимизации этого показателя надо работать по максимально четкому заданию. Уточнение формулировки задачи - лишнее потерянное неоплачиваемое время. Плюс переброс с проекта на проект не позволяет видеть общей картины.
2. Ограниченность объема памяти человека. Увы, чтобы думать в определенной области, надо иметь хотя бы базовые понятия о ней и иметь определенный опыт. А мозги разработчика уже сильно заняты кучей информации о структурах данных, синтаксисе языка, особенностях работы компиляторов и кучей других знаний без которых программа не состоится. Соответственно попытки думать пресекаются просто отсутствием информации.
3. Требование "делай как я сказал" от руководителей. Когда все попытки подумать пресекаются висящим сроком сдачи и нужно сделать "хоть что-то работающее" срочно. При этом четкая фиксация требований является той возможностью, которая уменьшает объем неопределенности.
4. Необходимость наличия навыков переговорщика и фассилитатора для определения взаимодействия сторон. Часто вижу, как люди работающие вместе по-разному видят процесс. Соответственно дают противоречивую информацию и это становится очевидно только при выслушивании мнения другой стороны о котором не было известно при постановке задачи.
Вот и получается, что думать на уровне бизнеса может руководитель проекта, который непосредственно на программирование времени уделять не может. Или же программист настолько долго работает в предметной области, что уже обладает понятийным аппаратом и негативным опытом от последствий плохих решений.
Что думаете, друзья?
Давайте порасуждаем, откуда возникает такая особенность поведения. Имея опыт работы и с ИТ-шниками и с людьми бизнеса, вижу несколько причин:
1. Оценка качества работа программиста на основе параметра SLOC - количества строк кода, которые были внесены в проект. Для максимизации этого показателя надо работать по максимально четкому заданию. Уточнение формулировки задачи - лишнее потерянное неоплачиваемое время. Плюс переброс с проекта на проект не позволяет видеть общей картины.
2. Ограниченность объема памяти человека. Увы, чтобы думать в определенной области, надо иметь хотя бы базовые понятия о ней и иметь определенный опыт. А мозги разработчика уже сильно заняты кучей информации о структурах данных, синтаксисе языка, особенностях работы компиляторов и кучей других знаний без которых программа не состоится. Соответственно попытки думать пресекаются просто отсутствием информации.
3. Требование "делай как я сказал" от руководителей. Когда все попытки подумать пресекаются висящим сроком сдачи и нужно сделать "хоть что-то работающее" срочно. При этом четкая фиксация требований является той возможностью, которая уменьшает объем неопределенности.
4. Необходимость наличия навыков переговорщика и фассилитатора для определения взаимодействия сторон. Часто вижу, как люди работающие вместе по-разному видят процесс. Соответственно дают противоречивую информацию и это становится очевидно только при выслушивании мнения другой стороны о котором не было известно при постановке задачи.
Вот и получается, что думать на уровне бизнеса может руководитель проекта, который непосредственно на программирование времени уделять не может. Или же программист настолько долго работает в предметной области, что уже обладает понятийным аппаратом и негативным опытом от последствий плохих решений.
Что думаете, друзья?