بديل Notion لإدارة المشاريع (احتفظ بالمستندات واكسب متتبّعًا حقيقيًا)

الكتابة في صفحات Notion ممتعة حقًا. وهذه هي المشكلة كلها، وهي السبب في أن فرقًا كثيرة تنتهي إلى البحث عن بديل لـ Notion في إدارة المشاريع يحتفظ بالمستندات ويضيف إليها متتبّعًا حقيقيًا للمهام.

تتراكم مواصفاتك ووثائق RFC ومحاضر اجتماعاتك في Notion لأن الكتابة هناك مريحة. ثم يحاول أحدهم إدارة العمل الفعلي داخل قاعدة بيانات Notion، فتظهر الشقوق. خاصية Status وسم ملوّن، لا سير عمل بفئات تعرف ما معنى «منجزة». لا يوجد سبرنت تبدؤه وتغلقه، ولا مخطط عمل متبقٍ، ولا سرعة إنجاز. الأتمتة محصورة داخل قاعدة بيانات واحدة ولا تمتد خارجها، فأي تغيير في صفحة مواصفات لا يستطيع تحريك المهمة التي تعتمد عليها. فيلصق الفريق أداة ثانية على الجانب، Linear أو Jira أو جدول بيانات، فيبدأ المستند والمتتبّع بالابتعاد عن بعضهما، ولا يربطهما إلا روابط منسوخة تتعطل لحظة يعيد أحدهم تسمية صفحة.

أنت غالبًا لا تكره Notion. أنت تكره الترقيع. هذا المقال لمن يريد الاحتفاظ بالمستندات التي يحبها والحصول على متتبّع يتصرف كمتتبّع.

إطار صريح قبل البدء: ‏Notion ممتاز فيما صُمّم له. سقف قواعد بياناته مرتفع (قاعدة البيانات الواحدة تتسع حتى 250,000 صف، حتى يوليو 2026)، فهذه ليست حجة «Notion ينهار عند أي حجم صغير». هو لا ينهار. النقد يتناول دلالات التتبّع، أي الفرق بين وسم يقول «قيد المراجعة» وسير عمل يعرف أن «قيد المراجعة» ليست «منجزة».

أين يبدأ استخدام قواعد بيانات Notion كمتتبّع بالاهتزاز

أعطِ Notion حقه أولًا، فهو يستحقه. قصة إدارة المشاريع عبر عروض قواعد البيانات حقيقية: عرض جدول ولوحة (كانبان) وجدول زمني وتقويم وقائمة ومعرض فوق الصفوف نفسها، وخاصية Status مبنية لهذا الغرض تجمع الخيارات في To-do / In-progress / Complete، وقالب Tasks-Projects-Sprints يربط المهمة بالسبرنت بعلاقة. حتى يوليو 2026، يستطيع فريق صغير فعلًا إدارة عمله في Notion، وفرق كثيرة تفعل.

والسقف مرتفع لا منخفض. قاعدة بيانات Notion الواحدة تتسع حتى 250,000 صف؛ يحذّرك Notion مع اقترابك من الحد ويمنع إضافة صفوف عنده أو فوقه (طلبات API تعيد خطأً قرب السقف). وكل صفحة محدودة بـ 2.5MB من بيانات الخصائص. هذه أرقام حقيقية، وهي عند معظم الفرق ليست موضع الألم. فدَع حجة «الأداة تنهار» جانبًا. الأداة تهتز، والاهتزاز دلالي.

ثلاثة مواضع محددة:

1. ‏Status خاصية، لا نظام فئات لسير العمل. خيار الحالة في Notion وسم ملوّن يحمل تسمية مجموعة. لا شيء في البنية يميز «قيد المراجعة» عن «منجزة» تمييزًا تثق به التقارير. اسأل «كم تذكرة حُلّت فعلًا في هذا السبرنت؟» وستجد نفسك تعدّ وسومًا، آملًا أن الجميع استخدمها بالطريقة نفسها. لا يوجد عمود فقري من الفئات يستند إليه أي تقرير.

2. لا كائن سبرنت أصيل، ولا مخطط عمل متبقٍ أو سرعة إنجاز من الدرجة الأولى. قالب Sprints يمنحك علاقة وبعض التجميعات، لكن السبرنت ليس كائنًا له تاريخ بداية وتاريخ نهاية وحالة تتنقل عبرها (مخطط، نشط، مكتمل) وترحيل تلقائي للعمل غير المكتمل. لا يُرسم لك مخطط العمل المتبقي ولا سرعة الإنجاز، لأن الكائن غير موجود أصلًا. إما أن تركّبها بيدك، أو تستغني عنها.

3. الأتمتة تعمل داخل قاعدة بيانات واحدة. لدى Notion واجهة API عامة وأتمتة لقواعد البيانات، لكن هذه الأتمتة تشتغل داخل قاعدة واحدة ولا تستطيع إطلاق إجراءات عبر القواعد. تغيير في صفحة مواصفات داخل قاعدة Docs لا يستطيع تحريك مهمة مرتبطة في قاعدة Tasks. الشيئان اللذان يجب أن يتخاطبا معزولان عن بعضهما بجدار.

الموضع الثالث هو القاتل الصامت. هو بالضبط الفجوة التي تدفع الفرق إلى إلصاق متتبّع ثانٍ على الجانب، ويبدأ الانجراف من اليوم نفسه.

ماذا يعني «متتبّع حقيقي» فعلًا (قائمة التحقق)

قبل مقارنة أي شيء، حدّد المعيار الذي تحاسب عليه الأداة. هذه قائمة التحقق التي أسلّمها لأي بديل لـ Notion في إدارة المشاريع، وسأقيس بها بقية هذا المقال حتى لا يبقى الكلام انطباعات.

المتتبّع الحقيقي يملك:

1. حالات سير عمل بعمود فقري من الفئات، لا وسومًا فقط، بحيث يصبح مفتوحة / منجزة / محلولة نظامًا تفرضه الأداة، لا عرفًا يتفق عليه الفريق ثم ينساه.
2. حدود WIP لكل عمود وقواعد للانتقالات المسموحة، بحيث تفرض اللوحة العملية بدل أن تكتفي بعرضها.
3. سبرنتات حقيقية: مخطط / نشط / مكتمل، بتاريخ بداية ونهاية وترحيل تلقائي للتذاكر غير المكتملة عند إغلاق السبرنت.
4. تقارير محسوبة لا مركّبة يدويًا: مخطط دائري للحالات، ومخطط عمل متبقٍ، ورؤى لمساحة العمل، مرسومة من البيانات لا ملصوقة في صفحة.
5. لوحة كانبان بالسحب والإفلات، وباكلوج مرتّب، وقائمة قابلة للتصفية، مع أنواع تذاكر (ملحمة، قصة، مهمة، خطأ) ومهام فرعية بعلاقة أب/ابن.
6. مستندات تعيش بجانب العمل، في الأداة نفسها، لا تطبيقًا منفصلًا موصولًا بروابط.

وهكذا يقابل Taskfolk هذا المعيار، حتى تستطيع التحقق بنفسك:

المعيار	كيف ينفذه Taskfolk
حالات مدعومة بالفئات	جدول project_statuses يحمل أعمدة مسماة وملوّنة ومرتبة لكل مشروع، يرتبط كل منها بواحدة من 7 فئات دلالية ثابتة (فصل Jira بين الحالة وفئة الحالة)
WIP والانتقالات	حد wip_limit لكل عمود وقواعد allowed_transitions لكل حالة، مفروضة على كل مسار كتابة للحالة
سبرنتات حقيقية	سبرنتات بحالات مخطط/نشط/مكتمل، وتواريخ بداية ونهاية، وترحيل التذاكر غير المكتملة عند الإكمال
تقارير محسوبة	تقارير لكل مشروع وصفحة ملخص (مخطط دائري للحالات + مخطط عمل متبقٍ)، مع صفحة رؤى لمساحة العمل، مبنية على Recharts
لوحة + باكلوج + قائمة	كانبان بسحب وإفلات متفائل، وباكلوج مرتّب، وقائمة قابلة للتصفية، وأنواع ملحمة/قصة/مهمة/خطأ/مهمة فرعية
مستندات بجانب العمل	قاعدة معرفة لمساحة العمل ومستندات لكل مشروع (التفاصيل أدناه)

احتفظ بقائمة التحقق هذه. هي تصلح لأي أداة تقيّمها، لا لهذه وحدها. وإن كان سطر الحالات هو ما يهمك أكثر، فمقال حالات سير العمل المخصصة يتعمق في فصل الفئات.

احتفظ بالمستندات: قاعدة معرفة لمساحة العمل ومستندات لكل مشروع

نصف الوعد القائل «احتفظ بالمستندات التي تحبها» لا يُحتسب إلا إذا رُوي بصدق، فهذه هي الرواية الصادقة.

لدى Taskfolk سطحان للمستندات: قاعدة معرفة على مستوى مساحة العمل ومستندات لكل مشروع. الفرق عمود واحد: ‏docs.project_id يكون NULL لصفحة معرفة عامة ومعبّأ لمستند مشروع. تتداخل الصفحات عبر parent_id وترتّب بـ LexoRank، فتبني شجرة حقيقية لا قائمة مسطحة. المحرر محرر كتل (BlockNote هو مصدر الحقيقة في body_json) مع مرآة Markdown مسطّحة (body_md) تغذي البحث والتصدير. تحصل على لقطات سجل الإصدارات مع الاستعادة، وتعليقات متسلسلة لكل مستند، وقوالب جاهزة فورًا: محضر اجتماع، وRFC، وتحديث حالة، واجتماع استرجاعي، وسجل قرارات، كلها ثنائية اللغة بالإنجليزية والعربية.

أمر واحد يهم في شكوى «الروابط المتعفنة»: التذكرة تستطيع الإشارة إلى مستند في سطرها. ضع رمز #d:<uuid> داخل التذكرة فيظهر شريحةً مسماة تصل مباشرة إلى المواصفة التي تحكم العمل، فلا تنكسر الوصلة إذا أعيدت تسمية المستند.

والآن الحد، معلنًا بوضوح لأن الأولى أن تسمعه مني لا أن تكتشفه لاحقًا. مستندات Taskfolk قاعدة معرفة قوية للمشاريع، لا بديل كامل لـ Notion في استخدامات الويكي العام أو إدارة المحتوى. تحديدًا:

• لا قواعد بيانات كمحتوى. قوة Notion الخارقة تحويل قاعدة بيانات إلى صفحة محتوى ببطاقات معرض وعروض مصفاة. مستندات Taskfolk لا تفعل ذلك.
• لا عروض معرض أو جدول زمني للصفحات.
• لا نشر لصفحات على موقع عام. المشاركة داخل مساحة العمل؛ الأسطح العامة هي النماذج ولوحة الملاحظات، لا المستندات.
• أنواع كتل أقل مما في Notion، ولا ادعاء بتحرير مشترك بمؤشرات متعددة. هذه قاعدة معرفة ذات إصدارات وتعليقات، لا لوحة تحرير جماعي مباشر.

فالوعد دقيق: أبقِ مستندات مشروعك بجانب متتبّع حقيقي، لا «استبدل كل استخدامات Notion». وللآلية الأعمق، مقال كيف تكتب مستندات المشروع يشرحها خطوة بخطوة.

اكسب متتبّعًا حقيقيًا: الحالات والسبرنتات والتقارير

هذا هو النصف الذي لا تصله عروض قواعد بيانات Notion.

حالات سير عمل مخصصة. جدول project_statuses يحمل أعمدة مسماة وملوّنة ومرتبة لكل مشروع. يرتبط كل عمود بواحدة بالضبط من الفئات الدلالية السبع، وهذا هو فصل Jira بين الحالة وفئة الحالة. هذا الفصل هو بيت القصيد: تستطيع لوحتك عرض «مراجعة الكود» و«في QA» و«بانتظار الاعتماد» أعمدةً ثلاثة، وتظل الأداة تعرف أنها كلها ترجع إلى الفئة نفسها، فتبقى is_open وresolvedAt وكل التقارير صحيحة مهما سمّيتها. يستطيع كل عمود أيضًا حمل حد WIP، وتستطيع كل حالة تحديد الانتقالات المسموحة منها، وكلاهما مفروض على كل مسار كتابة، لا في الواجهة فقط. هذا سير عمل، لا وسم.

سبرنتات حقيقية. السبرنت كائن بحالات مخطط ونشط ومكتمل وتواريخ بداية ونهاية حقيقية. أكمِل سبرنتًا فتُرحَّل التذاكر غير المكتملة إلى التالي تلقائيًا، بدل أن تختفي أو تبقى «مفتوحة إلى الأبد» بصمت. هذا هو السلوك الذي تحاكيه علاقة السبرنت في Notion دون أن تملكه. مقال كيف تدير سبرنتًا يغطي دورة الحياة كاملة.

تقارير حقيقية. تمنحك تقارير كل مشروع وصفحة الملخص مخططًا دائريًا للحالات ومخطط عمل متبقٍ، إضافة إلى صفحة رؤى على مستوى مساحة العمل عبر المشاريع. كلها مبنية على مكوّن Chart من shadcn فوق Recharts، محسوبة من البيانات، لا لقطة شاشة ملصوقة في صفحة. وهي جديرة بالثقة لأن الفئات التي تحتها حقيقية. مقال تقارير المشاريع والرؤى يبيّن مصدر كل مخطط.

اللوحة أعلاه هي المرساة: الأعمدة حالاتك المخصصة، والبطاقات تنسحب بينها بتفاؤل، والباكلوج والقائمة القابلة للتصفية على بعد نقرة. صفحة السبرنتات (مخطط/نشط/مكتمل مع الترحيل) وشبكة التقارير (المخطط الدائري مع مخطط العمل المتبقي) تحوّلان تلك اللوحة إلى شيء تستطيع فعلًا إدارة سبرنت عليه. وللشرح الكامل، راجع كيف تستخدم لوحة كانبان.

ولأن قواعد الأتمتة في Taskfolk تعمل عبر مساحة العمل كلها لا داخل قاعدة بيانات واحدة، تستطيع قاعدة «عند إنشاء تذكرة» توجيه العمل، ويستطيع تغيير في مستند إيقاظ المهمة التي تعتمد عليه. هذه بالضبط الفجوة العابرة لقواعد البيانات التي يتركها Notion مفتوحة؛ مقال كيف تضبط قواعد الأتمتة يعرض منشئ القواعد.

‏Notion مقابل Taskfolk: المقارنة الصادقة (الأسعار والدلالات)

الأسعار أدناه مثبتة حتى يوليو 2026 من بحث موثّق. وحيث لم تتوفر معلومة عن Notion في ذلك البحث، أسقطتها بدل التخمين.

	Notion	Taskfolk
أول خطة مدفوعة	Plus: ‏$10 لكل عضو شهريًا بفوترة سنوية ($12 شهريًا)	Pro: ‏$3 شهريًا ($30 سنويًا) لكل مقعد منفّذ
الخطة التالية	Business: ‏$20 لكل عضو شهريًا بفوترة سنوية ($24 شهريًا)	Business: ‏$6 شهريًا ($60 سنويًا) لكل مقعد منفّذ
خطة مجانية	نعم، بقيود	نعم، مكتملة الميزات؛ السعة هي السقف الوحيد
المشاهدون	يُحتسبون ضمن الأعضاء	مجانًا دائمًا، لا يُحاسبون أبدًا
حالات سير العمل	خاصية Status (وسم مجمّع بفئات)	نظام سير عمل مدعوم بالفئات (project_statuses)
سبرنتات ومخطط عمل متبقٍ أصيلان	علاقة في قالب؛ لا مخطط عمل متبقٍ أو سرعة إنجاز من الدرجة الأولى	سبرنتات أصيلة (مخطط/نشط/مكتمل + ترحيل) ومخطط عمل متبقٍ محسوب
أتمتة عابرة لقواعد البيانات	الأتمتة تعمل داخل قاعدة بيانات واحدة فقط	الأتمتة تعمل عبر مساحة العمل، بما فيها ربط مستند بتذكرة
رفع الملفات	5 MB على الخطة المجانية؛ بلا حد على المدفوعة	حسب مساحة تخزين الخطة (‏Free ‏128 MB)
سجل الإصدارات	‏7 أيام Free / ‏30 يومًا Plus / ‏90 يومًا Business / بلا حد في Enterprise	لقطات إصدارات المستندات مع الاستعادة على كل الخطط
SSO والتزويد	‏SAML SSO على Business؛ ‏SCIM وسجل التدقيق في Enterprise فقط	متاح على الخطط المدفوعة
الذكاء الاصطناعي	‏Notion AI ومعه Notion Agent محصوران في Business وEnterprise (تجربة محدودة لـ Free وPlus)؛ الذكاء الاصطناعي المتقدم بتسعير حسب الاستخدام: ‏$10 لكل 1,000 رصيد شهريًا فوق الاشتراك	برصيد مقنّن: ‏Free ‏25، ‏Pro ‏5,000، ‏Business ‏20,000 رصيد شهريًا؛ الوكلاء المتصلون أعضاء مجانًا
سقف قاعدة البيانات / الصفوف	حتى 250,000 صف لكل قاعدة بيانات	التذاكر علائقية، لا سقف صفوف لقاعدة واحدة

ثلاثة صفوف هي في الحقيقة الفرق نفسه بثياب مختلفة: الحالات وسم في Notion ونظام مدعوم بالفئات في Taskfolk؛ والسبرنتات علاقة في قالب مقابل كائن من الدرجة الأولى مع الترحيل؛ والأتمتة حبيسة قاعدة بيانات واحدة في Notion مقابل عملها عبر مساحة عمل Taskfolk كلها، وهو ما يسمح لمستند وتذكرة بالتخاطب.

الصف الرابع هو ما يفوته الناس: تسعير الوكلاء. في Notion، ‏Notion Agent وNotion AI محصوران في Business وEnterprise، والذكاء الاصطناعي المتقدم يُحاسب فوق ذلك بـ $10 لكل 1,000 رصيد شهريًا (حتى يوليو 2026). في Taskfolk، وكيل الذكاء الاصطناعي المتصل عضو في مساحة العمل بعلامة is_agent=1 ولا يُحاسب على مقعد أبدًا. إن كنت تنوي وضع الوكلاء على بيانات مشروعك، فهذا الفرق يتراكم سريعًا. وهناك مقال كامل عنه: هل يُحتسب وكلاء الذكاء الاصطناعي مقاعد.

وكن منصفًا حيث يتفوق Notion: سقف الصفوف لكل قاعدة لديه مرتفع، ومكتبة مستنداته أعمق وأكثر مرونة فعلًا من مستندات Taskfolk. إن كان مركز ثقلك المستندات، فهذا يهم.

وكلاء يقرؤون المستندات، لا المتتبّع فقط

هذا هو الجزء المختلف فعلًا، فيستحق أن نكون فيه ملموسين.

يوفّر Taskfolk خادم MCP رسميًا اسمه "Taskfolk". أدواته مشتقة من سجل OpenAPI، فيحصل الوكيل المتصل عبر MCP على كامل واجهة REST أدواتٍ جاهزة، لا مجموعة منتقاة يدويًا تذكّر أحدهم كشفها. المستندات جزء من تلك الواجهة: تحمل نطاقي docs:read وdocs:write وتغطي القائمة والتفاصيل والإنشاء والدفعات والتعديل والتصدير والتعليقات والإصدارات. وبحث مساحة العمل نقطة وصول واحدة تحت search:read تغطي التذاكر والمستندات معًا، مدعومة بـ Typesense ومتسامحة مع الأخطاء الإملائية، وهي أداة MCP أيضًا.

اجمع هذه معًا يستطع الوكيل ما يجعله إعداد Notion متعثرًا: يبحث في قاعدة المعرفة، ويقرأ وثيقة RFC التي وجدها، ثم يتصرف في التذكرة التي تحكمها تلك الوثيقة، متتبعًا شريحة #d:<uuid> من التذكرة إلى المستند. المستندات والمتتبّع عند الوكيل رسم بياني واحد، لا تطبيقان مخيطان برابط.

هذا هو النداء الرئيسي: ابحث في مساحة العمل، ثم اعرض المستندات. نقطتا الوصول هما GET /v1/workspaces/{slug}/search?q=...&types=issue,doc (النطاق search:read) وGET /v1/workspaces/{slug}/docs (النطاق docs:read).

# 1) Search issues AND docs in one call
curl -s "https://taskfolk.ai/api/v1/workspaces/acme/search?q=rate%20limit&types=issue,doc" \
  -H "Authorization: Bearer $TASKFOLK_API_KEY"

# 2) List docs (workspace knowledge base)
curl -s "https://taskfolk.ai/api/v1/workspaces/acme/docs" \
  -H "Authorization: Bearer $TASKFOLK_API_KEY"

const base = "https://taskfolk.ai/api/v1/workspaces/acme";
const headers = { Authorization: "Bearer " + process.env.TASKFOLK_API_KEY };

// 1) Search issues AND docs in one call
const q = encodeURIComponent("rate limit");
const hits = await fetch(base + "/search?q=" + q + "&types=issue,doc", {
  headers,
}).then((r) => r.json());

// 2) List docs (workspace knowledge base)
const docs = await fetch(base + "/docs", { headers }).then((r) => r.json());

import os, requests
from urllib.parse import quote

base = "https://taskfolk.ai/api/v1/workspaces/acme"
headers = {"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"}

# 1) Search issues AND docs in one call
hits = requests.get(
    f"{base}/search?q={quote('rate limit')}&types=issue,doc",
    headers=headers,
).json()

# 2) List docs (workspace knowledge base)
docs = requests.get(f"{base}/docs", headers=headers).json()

استجابة البحث تمزج النوعين في قائمة مرتبة واحدة (صفوف التذاكر والمستندات تحمل حقولًا مختلفة، تمامًا كما تسلسلها الواجهة):

{
  "data": [
    {
      "type": "issue",
      "key": "API-142",
      "id": "0192f3c1-9a4b-7de0-8c11-2b7f0a5e9d33",
      "title": "Rate limit returns 500 instead of 429",
      "project_key": "API",
      "project_slug": "api",
      "project_name": "Public API",
      "issue_type": "bug",
      "status": "in_progress",
      "priority": "high",
      "updated_at": "2026-07-14T09:12:44.000Z"
    },
    {
      "type": "doc",
      "id": "0192f3bd-77aa-7c02-9f5e-c1a0b8e42210",
      "title": "RFC: rate limiting v2",
      "icon": null,
      "project_slug": "api",
      "updated_at": "2026-07-13T16:40:02.000Z"
    }
  ],
  "pagination": { "next_cursor": "eyJvZmZzZXQiOjJ9" }
}

وقائمة المستندات تعيد صفحات قاعدة المعرفة بمتنها كاملًا:

{
  "data": [
    {
      "id": "0192f3bd-77aa-7c02-9f5e-c1a0b8e42210",
      "title": "RFC: rate limiting v2",
      "icon": null,
      "parent_id": null,
      "project_id": null,
      "body_md": "# RFC: rate limiting v2\n\nWe move to a token bucket per API key...",
      "created_at": "2026-07-10T11:03:20.000Z",
      "updated_at": "2026-07-13T16:40:02.000Z"
    }
  ],
  "pagination": { "next_cursor": null }
}

قارن هذا بصدق مع Notion. وكيل Notion قدير، لكنه محصور في Business وEnterprise ويُحاسب فوق الاشتراك. أما ربط وكيل بـ Taskfolk فلا يكلف مقعدًا واحدًا.

والحوكمة حقيقية، لا وعدًا على صفحة تسويقية. يمكن تقييد كل وكيل بقائمة الحقول المسموح له الكتابة فيها (صلاحيات كتابة الحقول لكل وكيل)، مفروضة عند نقطة الاختناق الوحيدة التي تمر بها كل كتابة عبر الواجهة، فالوكيل الذي يجب ألا يلمس إلا الحالة والتعليقات لا يستطيع إعادة إسناد العمل خلسة. وجلسة المراجعة أو الإنجاز التي لا نشاط منسوبًا فيها تكسب عند القراءة شارة «غير موثّقة»، فيلتقط الإنسان وكيلًا علّم شيئًا مكتملًا دون أن ينجز العمل. مقال امنح وكيل الذكاء الاصطناعي قاعدة معرفة يغطي مسار المستندات عبر MCP من طرفه إلى طرفه.

متى تبقى على Notion

أفضّل أن تتخذ القرار الصحيح على أن تنتقل ثم تندم، فهذه أسباب البقاء الصادقة.

ابقَ على Notion إن كانت حاجتك الأساسية ويكي عامًا أو نظام إدارة محتوى خفيفًا. إن كنت تعتمد على قواعد البيانات كمحتوى، أو عروض المعرض والجدول الزمني للصفحات، أو النشر إلى موقع عام، فـ Taskfolk لا يفعل هذه ولا يحاول. وابقَ إن كنت تعتمد على مكتبة كتل Notion العميقة أو التحرير الجماعي المباشر. وابقَ إن كانت مستنداتك تمتد بعيدًا خارج عمل المشاريع إلى ويكي الشركة الكامل، لأن مستندات Taskfolk قاعدة معرفة للمشاريع عن قصد، لا وثيقة لكل شيء بحجم Notion.

وهناك واقع الانتقال أيضًا. نقل مساحة Notion عميقة يعني نقل النصوص والبنية، لا نقل عروض قواعد بيانات اعتباطية وصفحات مثقلة بالخصائص واحدة لواحدة، لأن نموذج Taskfolk متتبّع علائقي مع مستندات، لا لوحة قاعدة-بيانات-كصفحة. إن كانت معظم قيمة Notion عندك في قواعد بيانات ذكية، فتلك القيمة تبقى في معظمها داخل Notion.

هذا دليل القرار السريع:

flowchart TD
    A[What is your center of gravity?] --> B{Mostly docs and wiki?}
    B -->|Yes, and public pages or databases-as-content| C[Stay on Notion]
    B -->|Docs plus real project tracking| D{Need sprints, burndown, workflow statuses?}
    D -->|Yes| E[Taskfolk: keep docs, gain a tracker]
    D -->|No, tags are enough| F[Notion databases are fine]
    A --> G{Putting AI agents on the work?}
    G -->|Yes, cost-sensitive| E

إن قرأت هذا وبقيت على Notion، فحسنٌ. النصيحة صُممت لتفيدك في الحالين.

كيف تنتقل دون أن تفقد المستندات

إن كان جانب المتتبّع هو ما جئت له، فهذا هو التسلسل الواقعي. هو ليس نسخة طبق الأصل، ولن أدّعي أنه كذلك.

1. صدّر النصوص والبنية من Notion. تصبح الصفحات مستندات Taskfolk. القوالب تتقابل بوضوح: وثيقة RFC تصبح RFC، ومحضر الاجتماع يصبح محضر اجتماع، والبنية المتداخلة تنتقل شجرةَ صفحات.
2. أنشئ المشاريع وحالاتها المخصصة بحسب طريقة عمل فريقك الفعلية، لا بحسب ما يظنه قالب افتراضي. هنا تحصل أخيرًا على الأعمدة التي طالما أردتها، مدعومة بفئات حقيقية.
3. استورد صفوف المتتبّع تذاكرَ عبر CSV أو استيراد من خدمة. الصفوف التي كانت تتظاهر بأنها متتبّع داخل قاعدة بيانات Notion تصبح تذاكر فعلية بأنواع وحالات ومُسند إليهم.
4. أعد ربط الوصلات. أشر إلى المستندات من التذاكر بشريحة #d:<uuid> حتى ترتبط المواصفة والعمل الذي ينفذها في أداة واحدة، لا برابط ملصوق.

وكن واضح العينين حيال الشقوق: عروض قواعد البيانات وصفحات Notion المثقلة بالخصائص لن تنتقل كما هي. ما تحصل عليه هو متتبّع نظيف والمستندات جالسة بجانبه مباشرة، وهذا ما كان يبحث عنه فعلًا معظم من يريد بديلًا لـ Notion في إدارة المشاريع.

حقيقتان تخففان الاحتكاك: تسجيل الدخول بالرابط السحري فقط، فلا كلمات مرور تديرها، والمنتج كله ثنائي اللغة بالإنجليزية والعربية مع دعم RTL كامل من سجل لغات واحد، فالفريق العربي أولًا ليس مواطنًا من الدرجة الثانية.

ولتفاصيل نقل بياناتك، مقال كيف تستورد مشروعك فيه الخطوات واحدة واحدة.

احتفظ بالمستندات التي تحبها، واكسب متتبّعًا يتصرف كما ينبغي لمتتبّع. إن بدت لك هذه المقايضة صائبة، استورد مشروعك وأنشئ لوحتك الأولى.