Убей в себе 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)
18/9/11 12:48 (UTC)Это слабая коммуникационная функция :) Я в один момент понял, что надо сообщать не точный факт, а подавать его в понятных собеседнику терминах. Плюс надо привыкнуть разговаривать привычными обычным людям паттернами :D
(no subject)
20/9/11 04:41 (UTC)мій імператив:
існування квантифікаторів "точно", "абсолютно" і т.п.
доводить, що будь-яка фраза - нечітка за замовчуванням.
люди не готові чекати прикидку, аби почути "не знаю, 30% что да",
вони вже на перших літерах кидають "ти што тупак?"
ця фраза звісна така сама нечітка, як і решта людських фраз -
десь на 4/5 істиності у десь 4/5 ситуацій %)
з людьми важко спілкуватись, а мабуть і не варто.
(no subject)
20/9/11 09:04 (UTC)Тут много чего надо участь. Например, такую, вроде, постороннюю вещь, как ранговый потенциал. Если поднять свой ранг, то от тебя сразу начнут хавать то, что раньше не хавали, иногда даже полный бред :D