Убей в себе IT-шника
13/9/11 16:29![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalenПридумал доклад-статью. Мыслей крутилось много, но как начал записывать - они куда-то схлынули, осталось немного флуда.
Коллеги, Вы замечали неудачные паттерны мышления, свойственные в основном айтишникам? Типа неспособности ориентироваться в нечёткой логике.
Если можно, с примерами и своими соображениями :) А я вас в докладе использую :)
Под катом мои соображения.
Конечно, способ складывать 2 и 2 существует только один. Не существует даже таких технических вещей, как “единственно правильный” язык программирования, фотоаппарат, автомобиль. И уж тем более не бывает единственно правильного устройства таких гуманитарных конструкций, как работа, бизнес, человеческое общество.
Яркий пример - какой-то IT-шник на политическом форуме высокомерно заявил о человеческом обществе: “Возможно построить надёжную систему из ненадёжных элементов - читайте фон Неймана”. Сам он его если и читал, то явно не понял. Из ненадёжных элементов, может, и можно - если эти элементы не анализируют саму систему, не выискивают в ней слабину и не занимаются активным противодействием.
Interactions over processes and tools. Почему так сказали? Потому, что люди а) должны помогать друг другу выполнять обязанности, и б) зоны ответственности должны перекрываться. В ситуации “Ты не сделал отчёт”, например, следует сказать “Я не напомнил тебе сделать отчёт”.
Если Вам нужно абсолютно чёткое разделение ответственности - значит, у вас конфликт вроде “- Ты не то делаешь! - Нет, это ты не то делаешь!”. Значит, у вас неэффективный контакт с коллегой/ заказчиком/ начальством, вам нужна какая-то документально закреплённая защита.
Может статься, что инструкцию напишут. И тут оказывается, что по инструкции Вы отвечаете за примерно в пять раз большую зону, чем Вам сейчас кажется. Скажем, за покрытие тестами. А как его сделать, если времени на тесты не дают? Идиотская инструкция! Неправильная!
Корень проблемы - в том, что автору инструкции (архитектору заказчика, например) и правда нужна такая метрика, но цену её достижения он не коммуницировал, потому что не продумал - или потому, что за человеко-часы он вообще не отвечает. А тот, кто отвечает, конечно, не заинтересован выделять людей, у него план горит.
Твитнуто Фаулером: There is an (unfortunate) belief that testers test, programmers code, and the separation of the two disciplines is important.
Документация всех спасёт. Аналитик должен делать правильные документы/(требования), тогда программисту всё будет понятно.
Миф происходит из 1) нежелания вступать в общение, 2) желания переложить ответственность на другого (мы всё делаем, как вы сказали!)
Никто и никогда не может дать полных и непротиворечивых требований на мало-мальски нетривиальную систему.
Порой понять, что от вас хотят, можно только долго общаясь об этом. Фиксируя знания и решения в документации, конечно. Но документация - это не главный инструмент, это - блокнот для памяти. Главный результат - понимание - рождается в общении. Документация - однородный документ, по нему не видно, что для заказчика важно, а что нет. Часто он сам этого не понимает.
Если Вы хотите общаться только через документы - значит, Вы не доверяете партнёру. Значит, Вы хотите ему сказать не “Вот, мы наконец вместе поняли, что тебе нужно”, а “Смотри, зараза, ты же мне сам вот это написал - получай!”. И будете тратить усилия на то, чтобы защититься от него, то есть усугублять недоверие и провоцировать дальнейшие конфликты.
Считает, что если он понял некий общий принцип, то понял всю дисциплину - например, изучил новый фреймворк. “Всё понятно, это как Rails, только на Java”.
И ещё считает возможным поучать других с высоты своего космического понимания. Если он довольно логичен и проворно пользуется гуглом, то такого “Гуглоневежду” бывает довольно трудно уличить в незнании. Помогает прямой вопрос - а что сделал ты.
В то время, как devil in details. “Принципы” - это только модели, а на практике важны различия между моделями и реальностью. “Теоретически, между теорией и практикой нет разницы; на практике, она есть”.
Это частный случай проблемы талантливого ребёнка - он с детства привык, что у него всё получается легко, с пол-пинка, и потом, если что-то получаться перестаёт, он начинает искать проблему в чём угодно - в коде программы, её архитектуре, операционной системе, "этой стране" - только не в себе.
Коллеги, Вы замечали неудачные паттерны мышления, свойственные в основном айтишникам? Типа неспособности ориентироваться в нечёткой логике.
Если можно, с примерами и своими соображениями :) А я вас в докладе использую :)
Под катом мои соображения.
Существует “правильный” способ делать что угодно
Конечно, способ складывать 2 и 2 существует только один. Не существует даже таких технических вещей, как “единственно правильный” язык программирования, фотоаппарат, автомобиль. И уж тем более не бывает единственно правильного устройства таких гуманитарных конструкций, как работа, бизнес, человеческое общество.
Яркий пример - какой-то IT-шник на политическом форуме высокомерно заявил о человеческом обществе: “Возможно построить надёжную систему из ненадёжных элементов - читайте фон Неймана”. Сам он его если и читал, то явно не понял. Из ненадёжных элементов, может, и можно - если эти элементы не анализируют саму систему, не выискивают в ней слабину и не занимаются активным противодействием.
Если прописать процесс с чётким разделением обязанностей, все будут делать то, что надо
Interactions over processes and tools. Почему так сказали? Потому, что люди а) должны помогать друг другу выполнять обязанности, и б) зоны ответственности должны перекрываться. В ситуации “Ты не сделал отчёт”, например, следует сказать “Я не напомнил тебе сделать отчёт”.
Если Вам нужно абсолютно чёткое разделение ответственности - значит, у вас конфликт вроде “- Ты не то делаешь! - Нет, это ты не то делаешь!”. Значит, у вас неэффективный контакт с коллегой/ заказчиком/ начальством, вам нужна какая-то документально закреплённая защита.
Может статься, что инструкцию напишут. И тут оказывается, что по инструкции Вы отвечаете за примерно в пять раз большую зону, чем Вам сейчас кажется. Скажем, за покрытие тестами. А как его сделать, если времени на тесты не дают? Идиотская инструкция! Неправильная!
Корень проблемы - в том, что автору инструкции (архитектору заказчика, например) и правда нужна такая метрика, но цену её достижения он не коммуницировал, потому что не продумал - или потому, что за человеко-часы он вообще не отвечает. А тот, кто отвечает, конечно, не заинтересован выделять людей, у него план горит.
Твитнуто Фаулером: There is an (unfortunate) belief that testers test, programmers code, and the separation of the two disciplines is important.
Документация всех спасёт. Аналитик должен делать правильные документы/(требования), тогда программисту всё будет понятно.
Миф происходит из 1) нежелания вступать в общение, 2) желания переложить ответственность на другого (мы всё делаем, как вы сказали!)
Никто и никогда не может дать полных и непротиворечивых требований на мало-мальски нетривиальную систему.
Порой понять, что от вас хотят, можно только долго общаясь об этом. Фиксируя знания и решения в документации, конечно. Но документация - это не главный инструмент, это - блокнот для памяти. Главный результат - понимание - рождается в общении. Документация - однородный документ, по нему не видно, что для заказчика важно, а что нет. Часто он сам этого не понимает.
Если Вы хотите общаться только через документы - значит, Вы не доверяете партнёру. Значит, Вы хотите ему сказать не “Вот, мы наконец вместе поняли, что тебе нужно”, а “Смотри, зараза, ты же мне сам вот это написал - получай!”. И будете тратить усилия на то, чтобы защититься от него, то есть усугублять недоверие и провоцировать дальнейшие конфликты.
Синдром всезнайки
Считает, что если он понял некий общий принцип, то понял всю дисциплину - например, изучил новый фреймворк. “Всё понятно, это как Rails, только на Java”.
И ещё считает возможным поучать других с высоты своего космического понимания. Если он довольно логичен и проворно пользуется гуглом, то такого “Гуглоневежду” бывает довольно трудно уличить в незнании. Помогает прямой вопрос - а что сделал ты.
В то время, как devil in details. “Принципы” - это только модели, а на практике важны различия между моделями и реальностью. “Теоретически, между теорией и практикой нет разницы; на практике, она есть”.
Это частный случай проблемы талантливого ребёнка - он с детства привык, что у него всё получается легко, с пол-пинка, и потом, если что-то получаться перестаёт, он начинает искать проблему в чём угодно - в коде программы, её архитектуре, операционной системе, "этой стране" - только не в себе.
Tags:
(no subject)
14/9/11 08:13 (UTC)Да и проектный подход вполне работает, чтобы недалеко ходить - у "Эппла" или, скажем, у Шаттлворта с Убунтой.