У Вас бувало таке відчуття перед підготовкою завдання або проекту? - хочу зробити супер-пупер-мега щось, і ось це додати, і тут прикрутити, а тут щоб феєрверк, а в результаті супер-пупер-мега великою стає різниця між задуманим і зробленим/напівзробленим та приходимо до "як хочеться, я не зроблю, а не менше я не згідна."
Часто кажуть, що управління ризиками - це уникання ризиків. Чим далі живу, тим більше погоджуюсь з цим твердженням. І борюся зі своїм перфекціонізмом :)
Отже, фактично, основна ідея, озвучена маркетологами Фейсбук - краще робити, ніж не робити. Вважаю, що це стосується і нашої сфери, бібліотечних проектів.
1. Move fast, break things. Рухайтеся швидко і не бійтеся щось зламати - ви поправите все, що піде не так і виграєте на швидкості прийняття рішень.
2. Done is better than perfect. Зроблена справа краща за “доведення до досконалості”. Світ змінюється так швидко, що немає сенсу робити довгі проекти. Є сенс запустити у “бета версії”, подивитися, як цим користуються і продовжувати вдосконалення вже на робочій моделі. Це не значить, що варто робити халтуру і робити якнайшвидше, навпаки краще робити роботу меншими порціями, не стараючись зробити все завдання зразу.
3. Code wins arguments. Програмний код розв’язує суперечки. Замість того, щоб витрачати час на дискусії і вагання - простіше написати програму і випробувати наявні гіпотези на практиці.
А що Ви робите, щоб Ваші ідеї реалізувались і зрушили з місця? Як підганяєте себе, чи воно Вам не треба?
