Проблеми

Є ситуація.
Перед вами йде людина, яку важко обійти. Є 4-и варіанти розвитку подій.
Ви можете йти за цією людиною, обливати її брудом і чекати поки вона поступиться.
Ви можете розвернутись і піти назад.
Ви можете піти вперед, і йти з цією людиною пліч опліч, але не обійти її.
Ну і на кінець, ви можете піднапрягтись, просунутись, обійти людину і піти далі.

Іншими словами. Є проблема, можна Ñ—Ñ— не вирішувати, жалітись яка ця проблема, нічого не робити Ñ– чекати поки вона “сама вирішиться”. Можна здатись Ñ– спробувати втекти від проблеми. Можна стати частиною проблеми. А можна взяти, напрягтись, Ñ– вирішити проблему.

Як часто ви, або ваші оточуючі власне віришують виникші проблеми?

Львівські Рельсисти збираються

Цієї п’ятниці будуть збиратись львівські Ruby on Rails програмісти.

Орієнтовна тема для першої дискусії: HAML чи ERB.

Місце проведення: Аля-мінута, УПА Героїв, 72
Дата Ñ– час: 10.12.2010(п’ятниця), 19:30

Ініціює збори команда Vertaline, в якій Ñ” відома людина з Рубі середовища – Олександ Бондар.

Більше інформації.

Java Users Group у Львові

На початку листопада буде збір львівського JUG-а.
Я постараюсь підготувати доповідь по одній з наступних тем:
– Spring Roo
– Maven 3/modern tools
– Методи серіалізації та обміну інформації

Може є якісь інші пропозиції тем?

Чому ви не заробляєте 4000$

Досить болюча тема. Всі хто працює в аутсорсі рано чи пізно задумуються над тим чому вони отримують наприклад 800$, 1600$, або навіть 2400$, а не наприклад 4000$. Остання цифра це приблизна зарплата програміста початківця-стажера в США. В рік виходить приблизно 50,000$.

Метою цього допису Ñ” спроба подивитись «у зеркало» та зрозуміти чому дійсно ми отримуємо такі суми тут. Найлегшим підходом до цього питання буде просто знайти відмінності між ними та нами. Описані речі Ñ” моїми суб’єктивними думками, тому бажаючі запрошуються до дискусії.

Відмінності я спробував по-сортувати по важливості.
1. Англійська мова.
За весь мій час роботи в ІТ я ні разу не зустрічав людини з fluent рівнем англійської мови. Людей з advanced рівнем можу порахувати на пальцях рук. Переважна більшість це різні градації intermediate рівня. Можливо ви скажете: «а вони нас Ñ– так розуміють!». І тут ви дуже глибоко помиляєтесь. Їм треба сильно напружуватись щоб зрозуміти про що ми говоримо, так як ми не говоримо “їхніми” словами. Це створює великий дискомфорт. Більше того в переважної більшості відсутні знання літературної мови. Тобто коли після роботи ви йдете випити пива з замовником, більшість може говорити тільки про проект. Язик розв’язується” аж коли всі трошки охмеліли, причому не через то що у вас підвищується рівень знань англійської, а через то що замовник «спускається» до вашого рівня.

2. Культурні відмінності.
Ніхто навіть не цікавиться ними. А вони є, і вони суттєві. Культурні відмінності впливають на то як ми мислимо і як ми сприймаємо інформацію. Наприклад, для американців є прийнятним коли керівництву заперечують. У нашій культурі це не є дуже типовим. Або наприклад для американців не є дуже прийнятною темою обговорювати своє приватне життя («як довго ви одружені?», «чи спілкуєтесь з батьками чоловіка?»). З цих двох прикладів друге просто створить певний дискомфорт під час роботи з вами, а от перше буде нести загрозу проекту. Так як цілком можлива ситуація коли ви завалите проект через то що погодились зробити роботу за 2 тижні в той час як вона вимагала 4 тижні. Ви скажете: «та він сам казав 2 тижні!». Так казав, але це була його думка, а вам робити, і то що ви не заперечили і не обґрунтували чому саме 4 тижні це вже ваша провина.
Таких відмінностей насправді дуже багато, можна написати невеличку брошуру по найбільш важливішим, проте всі є дуже важливими.

3. Технічний рівень.
Давайте подивимось правді в лице. Насправді у нас низький технічний рівень. Середньо-статистично, звичайно. Типово опускати наших програмістів на рівень нижче, щоб співставити з американськими. Тобто наші «сініори» насправді є американськими «мідами» і т.д. Чому так? На мою думку це є наслідком перегрітості місцевого ринку, коли щоб отримати більші гроші треба було іти на вищу посаду.
Люди часто не знають як використовувати інструменти. Наприклад дуже легко знайти джавіста який не знає Лінукс (під «знає» мається на увазі комфортна робота в терміналі), хоча більшість розгортань відбуваються саме на Лінуксах, або дотнетчика який самостійно не налаштує IIS для роботи в інтернеті (безпека, потоки, пули і т.д.) Ті хто це вміють вважаються справжніми «гуру» хоча насправді це стандартні вимоги і нічого особливого в них немає. Замість поглиблення знань у цих сферах люди кажуть стандартні відговорки: «а мені це не треба», «от є сініор, він нехай і робить», «це адміни робити мають», «ніде не сказано що я це маю знати», «я з тим не працював» і т.д.

4. Орієнтованість на бізнес
Багато з розробників не цікавляться що саме вони роблять. Вони отримують задачу, реалізують, тестують… і все. Не так і багато людей дійсно цікавляться яка бізнес складова стоїть за задачею. Результатом цього є не правильно визначені пріоритети. Наприклад інтенсивно тестують ті частини проекту які можна з багами випустити, а от критичні навіть юніт тестами не покривають.
Відсутність орієнтованості на бізнес породжує невірну інтерпретацію задач. Думаю всі бачили смішний малюнок про те що б було якби розробники робили гойдалку на дереві. Можливо воно і смішно, а от коли в житті це бачиш сміятись не дуже хочеться.

5. Культура праці
Під культурою праці мається на увазі не наш технічний рівень, а то як ми себе поводимо на роботі.
Типова поведінка: запізнюватись на мітінги, не вчасно подавати звіти, «забувати» про важливі речі, «губити» листи, самому «визначати» пріоритет завдань, відповідати на листи не в той же день коли він був отриманий і т.д.
Ще більш страшнішим є майже повна відсутність знань про процеси. Мало хто може дати правильну відповідь на питання «яка різниця між водоспадними та ітеративними процесами?», не кажучи вже про знання самих процесів.
Причому це не поодинокі випадки.
«Нам і так добре» скажуть розробники. Звичайно, але от нормально брати участь в командах де +30 чоловік ви не зможете, бо такі проекти без хорошої культури праці в принципі не можна зробити.

6. Використання інструментів
Можливо не найважливіший пункт, але один із найкритичніший.
Більшість просто не вміє користуватись інструментами. Ефективне використання Вікі, Екселя, PowerPoint є рідкістю. Є люди які не можуть назвати хоча б 3 редактори UML для Windows, не кажучи вже про роботу з під Лінукса. Можна знайти джавістів які не вміють користуватись Мавеном. Так само можна знайти дотнетчиків які не користувались ніколи Решарпером.
Мало хто на пам’ять знає комбінації клавіш стандартних рефакторингів з середовищ. Ефективна робота з колективними інструментами типу Exchange Ñ” рідкістю. Мало хто знає динамічні мови для полегшення рутинних щоденних задач.
Якщо порівняти з американцями, можливо кількісно число навиків є меншим, але кожен з них вони дійсно знають.

Звичайно є і ніші речі, однак на мою думку найважливішими є саме ці.
Ваші думки?

Крос пост з Розробки.

Відео з Lviv Startup Club 9.0 “Електронна комерція”

На Розробці опублікували нове відео з стартап конференції Lviv Startup Club 9.0 “Електронна комерція”.
Дуже цікава тема враховуючи ріст кількості інтернет магазинів та якість їхніх послуг.
наприклад особисто я користувався SoftKey.

Відео – Lviv Outsourcing Forum “Де знайти нових клієнтів?”

Опублікував на Розробці відео з нещодавнього Lviv Outsourcing Forum “Де знайти нових клієнтів?”.
Відео є в цій темі.
Якість середня, проте чітко чути.

Lviv Outsourcing Forum

Цієї суботи, 27 березня, буде на мою думку одна із найзнаковіших подій року в львівському ІТ – Lviv Outsourcing Forum “Де знайти нових клієнтів?”.

Що це таке? За формат взято Львів Стартап Клуб і накладено на львіські ІТ аутсорсінг фірми. Список учаників досить вражаючий, майже вся верхівка львівського ІТ. Як і з Стартап клубом половина користі у самих доповідях, а половина у спілкуванні під час кофібрейків.

Планую обовязково взяти участь.

Особистий розвиток

Починають постати все більш цікавіші статті на Розробці. Останні стосуються особистого розвитку:

Які повинні бути якості в хорошого програміста?
Мій досвід проведення презентацій
Станьте успішним програмістом

Цікаво, правда? ;)

Про Getting Things Done (GTD) українською!

Нещодавно на Розробці опублікували розширений опис підходу до тайм-менеджменту – Getting Things Done (GTD). Це здається перша публікація українською мовою про цей підхід. Робимо каву Ñ– сідаємо читати!

Орієнтованість на ціль

Відкрию спільноту дописом на дуже болючу тему – Орієнтація на ціль або результат, англійською result/goal orientation.

Сьогодні натрапив на дуже цікаву культурологічну статтю. Звичайно все описане є дуже прикрим та сумним.

Я спробую подивитись в корінь проблеми.

Якщо людина орієнтована на ціль, по мірі досягнення цілі вона може виявляти та усувати всі перепони які Ñ” на шляху. Якщо людина не орієнтована на ціль – перепони будуть накопичуватись та ускладнювати ще більше досягнення цілі.

Наприклад програміст орієнтований на ціль, якщо він повторює певні команди декілька раз, мабуть напише скрипт який буде їх виконувати за нього. Програміст який не орієнтований на ціль, мабуть і далі продовжить виконувати ті команди без автоматизації.
Таким чином перший буде виконувати поставлені задачі швидше та по ходу виконання буде отримувати більше досвіду. Другий програміст буде просто прогресувати вперед темпами нижчими чим перший.

Такий підхід застосовується і у житті. Людина яка орієнтована на ціль, міняє світ навколо неї у краще сторону.

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

Думки?